This is a huge inconvenience that I have refrained from reporting since I’ve used the beta type solver, yet particularly my migration from Sound instances into AudioPlayer became mind-boggling because the linter wouldn’t just warn that I was using a non-existent variable instead of the sound variable.
Except that enabling --!strict mode would just show that it was a typo and then in some other similar and extreme cases I’ve experienced, the process of renaming minor variables without Ctrl + F in non-strict scripts is just Minesweeper now in a dynamically-typed language.
Expected behavior
I don’t want to force all of my code to use strict mode especially that the type solver beta has been really callous each time a release note comes and then another bizarre type error shows up related to CFrame math and some library methods, and I have to use any or stick to LSPs on Visual Studio Code for other projects. I don’t want to sacrifice read properties and type functions either way now that I can’t think of leaving them.
If this might be a way to encourage strict mode, that doesn’t make sense when the previous type solver recognized unknown globals regardless if you were using strict or non-strict.
Hi there, thanks for the report! For some background, one major goal with the New Type Solver for us was to get non-strict mode to a place where it can be enabled by-default for everyone on the platform, even if they don’t know what a type system is, have never written a type annotation, and are just writing luau as if it was entirely dynamically-typed. Toward that end, we stripped back a ton of what non-strict mode did to target the specific goal of raising an error to the programmer if and only if we can prove that there will always be a runtime error at that point. When that’s the case, the error we can provide in can be rooted entirely in the dynamic semantics of the language, and therefore not require the programmer to understand types at all. None of this was done to “encourage strict mode.”
After the release, based on feedback from users, we added support for unknown symbol errors in the new non-strict mode because, even though it doesn’t always lead to a runtime error, it does meet the more general criteria of being able to be explained to the programmer entirely in terms of the dynamic semantics of the language, and not requiring an understanding of types. This is on and working in general, and has been for at least a month (though forgive me, I forget the exact release it came out in).
I see that you’re somehow not getting the error in your screenshot, and this is indeed a proper bug, likely because of some oversight in what bits of the syntax the non-strict type checker visits (since it was originally written to only be concerned with function calls, in some sense). If you provide your code (or a minimized reproduction version of it) directly, instead of as a screenshot, this can almost certainly be fixed very easily.
P.S. I’m not going to try to convince you to use strict mode, even if I’d like to personally believe it is worth the cost of business, but what exactly do you mean by “the type solver beta has been really callous each time a release note comes?” I don’t really think of software as something that can be callous, but if you mean to suggest that someone on our team (including me) has been somehow callous about users of the product, I’m happy to look into that and offer any appropriate apologies and mitigations. Our intention on the Luau team is certainly never to be insensitive or cruel towards our users and their needs.
1 Like
Hi! English isn’t really my first language so I had to use a word that made sense regarding the situation, so I’d like to apologize if that sounded mean and that I’m not really sure what’s going on with the type solver beta as of recently. I’ll give a repro if possible. Thanks!
1 Like
