It thought/hoped Studio would know that player1 is a Player object, and that intellisense would know these members. Is that not the case? I ask as it seems like it should know that, but my Studio doesn’t, so I’m starting to think I need to re-install it.
I’m not a Roblox engineer, but here’s my understanding on how it works:
Intellisense doesn’t assume that a function will return an instance. After something not guaranteed to return, like FindFirstChild or GetPlayerByUserId, it could have the variable set as its return become nil. Since indexing nil doesn’t make sense, intellisense doesn’t make any assumptions on whether or not it can index in these cases.
It should
Unless I’m mistaken, only two things can be returned; nil or a Player object.
It would certainly make coding easier if it made this assumption.
Going off that, the function GetPlayerByUserId() is a roblox API service function, so it would need to run code to assume what type of instance it is getting back.
In any case, you wouldn’t want to use intellisense for this, because a nil object may be returned. You should first check that the function returns a player object first. And then index.
Heres what intellisense is good for though; all roblox objects can be represented as table datatypes. So intellisense can see what data is already available in your game, but it cannot run code and compute what data might exist on run-time.
Isn’t it common practice to have suggestions for the possible return types? (At least it does in IDEs like PyCharm, where functions that may return an object have suggestions for it even if it may return None.) It may return nil, but most of the time it will return a Player object, and someone might like to see suggestions related to Player if it is. If the return type is properly documented it wouldn’t need to execute the code.
Thats true, if it is documented then code execution isn’t required.
I’m guessing because lua can return any datatype, roblox didn’t install this implementation. They would need to have at least some uniformity expecting returned datatypes between service functions and user-made functions.
I can see this being much easier to implement in languages like C/ C++ where all functions have an expected return type even classes. But it is cool how PyCharm has that.
It’s definitely harder with dynamically-typed languages, but not impossible. There are many Python type checkers out there that can check variable, argument, and return types just fine. Sometimes they can be obvious to the type checker (a function with a = {}; return a can easily have dict suggestions), sometimes they may need the exact value defined by the programmer.
In the case of Roblox object methods, they can all have defined return types such as Player. There is already limited support for this (e.g. if you have a = game:GetService('Players') and type a.MaxP then “MaxPlayers” appears). They just have to expand it to more methods and properties. I’m not a Roblox engineer though so I wouldn’t know the technical challenges of it.
ModuleScripts and Remote/Bindable Events and Functions would be pretty hard though. I think Luau is supposed to help with this in some way by letting you define the types of variables and such.
Well python null types are actually implemented differently. Say you want to index a table tab = {foo = 0, bar = 1}
An if statement tab[foo] returns 0, but tab[non] will generate an error because non doesn’t exist in the table. You would need to use the keyword in to check if non exists in tab.
However, in lua we default to null values, such that all keys exist but do not always have values. I think this difference in memory storage complicates it for roblox.
When it comes to editor autocomplete the concept is the same though. You’re expecting to get suggestions for possible return types for the times it doesn’t return whatever the null value is (None or nil or anything).
idk, I don’t use much IDE’s. Only terminal.
It’s just an implementation that has to be developed by the platform, and it’s likely that there are complications with Lua.
I can see it possible, Roblox could say if certain service functions are called to assume that the return types have certain properties/ indexes.
But say you don’t initialize an element, like tab={foo=1, bar=nil}; return tab
How could roblox editor know when to suggest element bar if bar is as well known as an element that really doesn’t exist.
It could probably suggest based on what the other values are, since tables often contain multiple values of the same type.
local t = {foo=1, bar=nil}
mystery_function(t)
print(t['bar'])
-- could be int since the others are, the dev probably knows what to expect even if the type checker is not 100% sure
Is that really a problem? Runtime checks for nil (an obviously good practice) and intellisense during coding seem to be unrelated. Can’t the vast majority of classes/objects be, at some stage, nil? Does that mean no intellisence for them?
Keep in mind I’m not talking about some custom class that I’ve written. Player is a Roblox class.
Well currently since the value would be known at runtime, anything can happen. There is no guarantee for functions like Instance::FindFirstChild, Players::GetPlayerFromCharacter, etc. to return a child with a given name or a player from a given model. As already mentioned, indexing a nil value makes no sense. Most beginners would probably be misled and assume that because there is intellisense, that the instance is guaranteed to exist.
Just because it might return nil doesn’t mean it should give up entirely. Not giving suggestions is not useful to developers in any way. From a type checker’s perspective it has two possible outcomes: it returns nothing or it returns a Player object. The latter is much more likely to happen and chances are a developer is working around the possibility that it might be nothing. In that case it should help the developer use the result in the cases where it is the expected return type.
