I’m assuming what you’re proposing is that if the property doesn’t exist, it just returns nil? There are certain properties that already can be nil, so that wouldn’t work at all.
Should Roblox give us some way to check if properties exist? I guess there are some use cases there (but limited). Is this the way to do it? In my opinion, definitely not.
List more use cases for why throwing an error logically makes no sense here, because it does for me.
The example given was just a single case that i thought of, not necessarily a good one. The request here is not to have a method of getting a parts properties.
As for there being properties that can have a value of nil, you don’t have to check those.
The use case here is when you know the property can’t be nil. Say you wanted to check a bunch of different objects to see if they had a certain property, and you know that properties value can’t be nil. You loop through them, and if they are nil you know it doesn’t have the property.
It’s generally a small annoyance, but i’ve had it multiple times in the past. I’m proposing to remove it because i don’t see any use cases for it and it’s sometimes bothersome.
Instances are not tables. The errors are good because it’s better if your code fails earlier rather than later so that it is easier to pinpoint the issue. You lose a lot of explicitness if you remove these errors from nil indexing.
What’s the problem with having to pcall to know if an object has a property? This is a niche use case anyway, I’ve only ever seen the use case of needing to know properties of a class in plugins, and only a handful of them.
You just gave that exact piece of code that would be broken in the first sentence here. If it doesn’t error anymore, the pcall would go through since it doesn’t give an error anymore. Subsequently this code would assume the property exists.
It would. Generally speaking, there are very few objects that have the same property names that do not inherit from the same class. It seems like it should be cleaner to have a instance:IsA(a) or instance:IsA(b) or ... chain than to say if pcall(function() local a = instance.Property end))
And it is important to keep the error for debugging purposes. Like @buildthomas said, instances aren’t just standard tables. They are an API to Roblox’s engine code, and that means they have set properties. If you were to set Transparency to something on a BindableEvent instance, that should error because it simply does not make sense.
Multiple people seem opposed against this change though, so I guess i give up. You’re correct about it being a very niche use case. I had previously questioned whether or not to post this request because of that.
And yes, I missed the issue where removing the error would break code that currently relies on the pcall returning false.
To add on to what is already said, you as a developer know what instances you feed into your functions. I can’t think of any single situation where you have random instances fed into your functions.
All default Roblox instances have a classname you can identify them by, which means you know what properties and methods are available for them. Your issue with multiple instances sharing properties can be solved by checking their base class. You can also assume that most classes have the Name, Parent and Archivable properties due to the nature of these properties.
I didn’t make the post without a reason for it. There was something it was preventing me from doing, which i fixed by parsing the api manually for the properties. It involved using metatables to create custom objects. The metatable __index checked the object to see if the index existed, and if it didn’t it accessed the custom object table instead. But it threw an error, requiring me to run pcall() or parse the api manually.
Here’s example problem code that does similar
Had i left it with pcall, it would run it every time i indexed the object, which could be very slow even for relatively light things.
I definitely don’t want nil indexes to do anything other than error, this is one of the major faults of JavaScript. When you mess up, it’s not immediately obvious and you could spend minutes to hours debugging to figure out the issue. If you were to include warnings like you said, that sounds even worse, whenever I would abuse a use case of the feature my console would be flooded with warnings.
