For the reasons we mentioned in previous feature requests for this feature, we do not have plans for type inference of custom require function wrappers.
Reason being that cross-module dependencies are resolved before typechecking can even start. It’s unrelated to the architecture of old or new solver themselves.
3 Likes
Enabling this feature crashes Studio entirely within 30 seconds of opening one of my projects that uses React. Should I upload the log here or would it be better to DM instead for that?
Same thing happens to me. I imported from file react-lua into a basic baseplate and it crashes in less than 10 seconds. I can also produce a log if needed.
nope. it not, index and rawget are simply type functions that allow you to get the type of an value from an index in a table by providing the “class” and the “index string name”
like this:
local class = {
["foo"] = Instance.new("Part")
}
type test = index<typeof(class), "foo"> -- Part
not comparable to the valueof type function.
the suggestion i provided is for the arrays string values, actually you can’t get the valueof arrays (it gives you a singleton type)… i think thats stupid.
type Array<T> = {T} -- single type like string and more
i ask to have all the string values of the array:
local enum = Enumerator.new(
{
"Stone",
"Dirt",
"Grass",
}
)
-- type of the enum:
type enumObjects = "Stone" | "Dirt" | "Grass" -- thats the thing i want.
type enum = { [enumObjects ]: number } | { [number]: enumObjects }
Calling things stupid is not a constructive or appropriate way of leaving feedback, and you actually didn’t provide any suggestion at all because you didn’t even attempt to describe what your expected behavior for your imagined valueof type function was.
Your etiquette aside, index more-or-less does what you want except that you’re not currently able to index by number. This isn’t a fundamental limitation, we’ll enable that in an upcoming release, but specifically for literals in particular that you want to use to emulate an enumeration, you may currently need to cast them explicitly to their singleton type. In general though, you’re probably better off directly using string singletons, rather than trying to map them to and from numbers. The former is considerably less error prone, and doesn’t require you to try to pull any special shenanigans to make the types work.
7 Likes
I love the keyof and index things but holy crap this ruined my code
I really liked the fact that when accessing the explorer hierarchy, it made all the types & any so that it wouldn’t go crazy whenever Im expecting a certain setup that isnt there immediately in studio. Evidently that does not happen anymore and my code is riddled with warnings. Not to mention theres a weird issue when iterating through a list using the for i = 1, #list do format, probably because of the use of the #. I really dont like how much typecasting and rewriting this change makes me do to make everything function, I thought this was supposed to reduce how much of that I needed to do? The number of warnings and the amount of time I need to invest to fixing its various warnings this introduces makes it completely unappealing to me. I may end up ditching --!strict if this pushes at all like it is right now.
(edit: sorry for the notification “Skilled”, I keep accidentally replying to random posts instead of the topic itself)
1 Like
This means that with the new type solver, defining types for variables, table entries, and other parts, will enhance code performance.? Can we expect a noticeable increase in performance as a result?
I think this is more of an issue with how you wrote your code vs the new solver. Although you didn’t show any code so I could be very wrong here.
But as far as I can understand this is a complaint about you having to actually validate things that arent guaranteed to be the way you intend with :IsA.
Theres a reason this is a beta, its not fully ready
Theres a known bug with #tbl being inferred as boolean, but this also seems like an issue with your code. As its not recommended to iterate over tables like that, and its instead recommended to use generic iteration because its faster, easier, and less lines you need to write for i, v in tbl do
The Luau type system is still fundamentally an optional type system, and is used to provide a better developer experience (including powering autocomplete and type hover for both Studio and VS Code through luau-lsp). It may in the future be used to improve the performance of code in certain environments (this already happens in certain cases when using native code generation), but nothing in this announcement is about fundamentally changing that. Rather, we’ve been working on making considerable improvements to the developer experience side of things, but need people to try it out to help direct our energy towards the highest priority issues and to help us best understand where the new solver still needs to grow before it’s ready to replace the original one.
1 Like
Will the new solver be updated soon with fixes that have been reported on GitHub? I really want to continue developing and updating my module to the newest type system, but I keep getting blocked warnings and other errors.
1 Like
Luau updates with the same release cadence that Roblox and Roblox Studio do. We are working on new updates and will continue to be patching the Beta every single week, but they are released on GitHub on Fridays and don’t make it to Roblox until the following Thursday.
2 Likes
I’m experiencing extreme memory usage with this feature enabled in an old game I maintain “Sandbox.” With it disabled memory usage doesn’t go much over 2GB. Autocomplete also doesn’t appear while trying to edit any scripts in the place.
2 Likes
uhh this doesn’t feel intentional
1 Like
Memory issues are known, this is due to the solver having to infer lots of really big types because it doesnt simplify them currently. This is currently being fixed but idk when it’ll be out.
You can cast things that appear to have really over complex types to help out the solver right now though
1 Like
I can say that it is in fact a complaint about needing to use :IsA for everything. Typing is supposed to make things safer and more convenient at a small time expense, but having to type check and double check the existence of every single object you want to use, may be a bit safer, but is far less convenient, slower, often unneccessary, and has a large time expense. Im really hoping that its just a product of being a beta, and not an intended change.
As for the reason I was iterating through a table like that, I did actually have a reason. I was iterating through the loop and removing some elements. Im not entirely sure if lua handles it differently, but from habbits made in other languages, I iterate through a loop backwards when removing elements to prevent elements shifting from messing up my code. What I showed there was not actually code that I used, just an example. What I actually used was for i = #list, 1, -1 do. Generally, I do iterate through tables the normal way.
3 Likes
This feels like it could be a cool Studio update, but my type definitions and stuff don’t seem like they’re advanced enough to really say if it’ll be worth it for me personally.
Still, I think I found a bug. In my experience, I use a module to store instance references and stuff for characters. I’m probably misremembering, but I think Studio started failing to auto-complete functions, give their parameters correct typing, or something. To work around this, I manually typed everything, defining the module’s contents as the module’s empty table is created. like this:
local CharStorage : {
GetDictionary : (self, _reference : string | Player | Model, _quick : boolean) -> (CommonType.CharacterEntry?),
SetupCharacter : (self, _guid : string, _characterOrPlayer : Model | Player?) -> ({
Success : boolean,
GUID : string,
Entry : CommonType.CharacterEntry
}),
LinkSaveData : (self, _reference : string | Player | Model, _key : string, _saveTable : {any}) -> (boolean),
RemoveCharacter : (self, _reference : string | Player | Model, _completelyRemove : boolean) -> (),
EnsureEntrySafety : (self, _entry : CommonType.CharacterEntry, _noWarning : boolean?) -> (boolean)
} = {}
What's 'CommonType'?
“CommonType” is a reference to another ModuleScript that just contains type definitions, which is correctly parsed by auto-complete’s preview:
With the old type solver, it just worked. Whenever I required then referenced that module with a colon, everything appeared. I don’t know why the “self” arguments became *error-type*, but that isn’t the bug (ignore my message in the last screenshot).
After enabling the new type solver, Studio doesn’t suggest any functions when I type
CharStorage:. It only works if I use a period instead, but this isn’t my preferred style.
I’m guessing this bug is caused by the “self” definitions. The old type solver couldn’t determine that parameter’s type, but it still auto-completed everything correctly. (I know Studio’s smart, too; If I define functions that don’t use a table as their first parameter, they don’t appear when I use a colon.) Maybe the new type solver is trying to look deeper and it’s determining that
*error-type* can’t be a table, so it hides all of the functions?
EDIT #1: I wonder if replacing the “self” typing with a reference to “CharStorage” would fix this… I’m not sure if that’s even possible since this is inside the definition for the same table I’m already defining; Technically even defining the type as an “export type” block then referencing it on the table itself would have the same problem.
EDIT #2: I was unsure whether it would work, but I tried defining a “type” for that module’s contents, and found that I could use that definition for the self parameter, and assign the definition to the module’s table. Now I can reference it using a colon with the new type solver. 
2 Likes
We have an RFC open for shared self type inference which we hope to implement soon in the new solver and which will hopefully eliminate the need to explicitly specify the self type like you’re doing here, but yeah, the solution you came up with is what I would recommend for now (and really, it’s exactly what the type solver will do to infer the type itself too). Explicitly annotating the self type for each method is the most consistent way to get proper typechecking and autocompletion for colon-style function calls currently.
3 Likes
[Bug] I just found a bug, this type solver say the b variable is typed as “true” but i typed Test as
{b: boolean} so it must be setable as “false”
.
2 Likes