--!strict
local part: BasePart = Instance.new("Part")
local part2: BasePart = Instance.new("Part")
part2.Name = "A"
part2.Parent = part
print(part.A)
When I put this code inside of a script.
It underlinded A with warning: “Key ‘A’ not found in class ‘BasePart’”. How to fix this? Is this a bug? If so, then why hasn’t Roblox fixed such an obvious bug?
There are no errors when the script is ran. Just in the editor it is underlined.
I know I can just turn off strict mode, but that is not the point.
Not a expert on luau but I believe it is because the linter can not tell that ‘part’ has a child ‘A’ until runtime when it will be set. Idk what the best work around for this is but you can use FindFirstChild instead.
Probably not a bug. Properties of an Instance have higher index precedence than a child so script analysis is probably assuming that you’re attempting to read a property not a child. Things like this are probably why some developers feel it was a mistake allowing child access by dot syntax.
My two cents, could be wrong. I’ve only recently started using typechecking and it’s all been in VS Code with pure script environments. I’ve never actually used typechecking in Studio, much less with instances beyond for loops, CollectionService or a direct ancestor.
It’s giving a warning because it thinks you’re trying to index a property. You can simply silence it by adding .Name if you want to print the part’s name which is what you should be doing anyways.
(in Studio it also shouldn’t give a warning)
Also, you don’t need to manually note the types for every variable, it infers most types automatically for you.
As far as I’m aware currently, without use of FindFirstChild or another form of getting children (e.g. from GetChildren) that isn’t dot syntax, can’t fix that.
@zamd157 This is for assigning a type to a child item, not for getting a name (?). As for type inferencing, aren’t there supposed to be improvements in the future if you strictly declare type as opposed to inferencing? Seems like a good habit to declare types for variables from what I know.
That or let the typechecker infer on its own and don’t declare types for variables that might be child references. This might be something you want to raise as a feature request or as a point of concern/question for the next Luau update thread, a staff member or someone more familiar with typechecking may be able to inform you what to do with child typechecking (assuming this thread doesn’t eventually get resolved).
He’s trying to print the part (which prints the name). When you tell it to print the Name, the type checker will understand A is not a property, but rather a child, and doesn’t leave a warning.
I have no idea how they’ll make the optimizations with the type information, but they’ll most likely get the cached types from the inferences to make it work.
If you think it’s good, that’s your opinion. I don’t think there’s a reason to because most likely you’ll know what type those are.
That’s a fair circumstance. I’m under the impression that this is purely test code though and not representative of an actual environment wherein those variables might actually need to be references to child objects and not just whatever tostring returns.
If that doesn’t work on Studio, I guess that’s a feature request!
If you really want type checking, try using VSCode with Roblox LSP because it’s a way better tool than the built-in script editor.
It’s not a bug, the linter can’t predict the future descendants of a part unless you use explicit references to them. You’d have to use FindFirstChild to alleviate the warning.
