This one causes problems to mine studio (I can not get feedback on my code anymore) so i disabled it. I rather be using the current Type Solver.
You might want to check out the RFC on User-Defined Type Functions, which is probably the closest thing to your request. Theoretically, your example could be something like
type function FrameworkGet(path)
if not path:is "string" then
error "path to get must be a string!"
end
-- From here on, this wouldn't actually work even if the RFC was accepted, but still interesting to think about
local found = game.ReplicatedStorage:FindFirstChild(path)
if not found then
error "path not found"
end
local ok, script = pcall(require, found)
if not ok then
error "failed to require script"
end
return script:properties()
end
function Framework.Get(string: T): FrameworkGet<T> end
However, this example wouldn’t work because globals including “game” and “require” shouldn’t exist in type functions, as their runtime is designed to be constrained so they could be run both at compile-time and at runtime. They’re also designed to run only in the Luau VM, so Roblox-specific features wouldn’t work, and an API to allow this seems like it would be out of scope for Luau itself.
Type functions would still have loads of uses in their state in the RFC though, and I’m still really excited about them.
3 Likes
local Selection = game:GetService("Selection")
for _, v in Selection:Get() do
if v:IsA("ImageLabel") or v:IsA("ImageButton") then
print(v)
end
end
It refuses to give autocomplete if there is more than one possible type it could be.
I would personally prefer it showed variables both classes have such as .Image while hiding .PressedImage since only textButton has it.
This is a known issue and one of the reasons we mentioned that the Beta does not work well in larger projects.
We also can’t promise that some of these issues will be solved soon, but we are certainly looking to solve them before the full release.
1 Like
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.
4 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