2 Likes
Not atm, but I made an RFC for it, if it gets accepted, variadic type functions can be implemented into the language.
2 Likes
Lovely! Makes it feel much less hacky to use type functions and I feel like I can easily understand what is going on and what the output will be. Made my own pretty printer and equal functions, but how do I share them to other moduleScripts to use within other user-defined functions? They are each 100-300 lines, so copy-pasting them is out of the question (unless I need to).
I know I can use the functions from types easily, equal<A,B>, but really stumped. If it isn’t supported and will be later, then I’ll wait until it is.
1 Like
When is the fix for detecting typo’s?
We intend on having this work eventually. The missing feature right now is that user-defined type functions cannot currently refer to arbitrary type aliases from their environment. Once they can do that, you’ll be able to access other user-defined type functions under required libraries just like you can access exported types in general. The reason it depends on this is that Luau functions on a per-file basis, and so we cannot see that the type alias refers to a type function versus something else.
2 Likes
Hello , after 1 week of bugs on my studio, this means: When I close Roblox studio, the page remains and it’s bugged I can’t do anything anymore
Same bugs on Window 10 |Window 11
I would like to point out that one of my friends also tested it and had the same bugs as me.
Other bugs that prevented me from dev are the auto completion that stopped working and also the Analysis script.
This is the culprit, DO NOT ACTIVATE IT UNTIL THEY FIX THIS PROBLEM, thanks you !
4 Likes
I also am having similar issues, I just enabled The new Lua type solver to test it out because the old one was acting up and it completely broke studio, The first time I enabled it, it caused multiple icons to fail to load, including multiple textures in the game, as well as it caused the sky to become pitch black. upon closing studio it fails to close properly and requires me to force quit. I also had one attempt where I attempted to load studio and barely anything loaded at all, and it left me with a mostly blank app where nothing was functional.
I am on a MacBook Pro 2023, Using Sonoma 14.6.1
2 Likes
Before getting this out of the beta, would you mind if you add a feature where the type solver knows in which run context a module is on? Modules can be required by both the client and server. Some people also use RunService’s IsServer(), IsStudio() and IsClient() to get the module’s current run context and script an if statement to return the client or server-sided variable. This works, but the type solver gets confused on which run context it is running on (i.e. inside of the IsClient() if statement, inside of the IsServer() if statements, and inside of the script that required them).
Thanks!
1 Like
I am experiencing an issue with the ‘Incremental typechecking and autocompletion in studio’ beta feature.
When typing an if statement, I suddenly typed if ... task instead of the normal if ... then,
so when I went to check the autocompletion list it indeed showed this:
Thanks to some help in the post pointing to this beta feature, I turned it off to check and indeed it solved the issue
2 Likes
I have this same issue. I have no clue what this “incremental typechecking” thing is, but whatever it is, it broke the autofill for half of my code, and it seems to have enabled itself. When I enable type hover, I have my types properly annotated and it shows “ClassName” when I hover over self, so the type checker is most definitely recognizing the type, however autofill just doesn’t work when i try to type self.property???
the “then” autofill also no longer works for me, and this threw me off because I was so used to type “t” then hitting enter and now it fills with “task” or something every time
1 Like
I believe this is not directly related to the new type solver. Enabling the beta basically just adds --fflags=LuauSolverV2=true when analyzing the scripts. It is moreso related to ScriptEditorService and Enum.CompletionItemTag.ClientServerBoundaryViolation.
Minimal How To
You can actually make it yourself by checking the ClassName of the script. You may have to create your own system though, like @server in the documentation means it should be hidden for the client. You can then add the ClientServerBoundaryViolation tag if the item is in the incorrect script context.
If you are trying to make clientonly or serveronly properties that aren’t functions, it is more difficult, but you can do it.
The script context can be found using:
game:GetService("ScriptEditorService"):RegisterAutocompleteCallback("1", 1, function(request, response)
if request.textDocument.script.ClassName == "LocalScript" then
-- Client Context
else
-- Server Context
end
end)
1 Like
Hi!
Thanks for reporting this issue. Incremental typechecking is a feature that is designed to improve autocomplete latency by typechecking a fragment of your script and then providing type information for it.
This is currently in Beta, and can be disabled in the beta features menu to return to the old autocomplete solution. The problem you mentioned regarding self is a known bug that we are working on fixing.
Re: the then else elseif autofill, this has also been fixed by a recent flag flip - if you restart/update studio it should work now.
2 Likes
Hello, I also ran into some autofill issues in this post, I believe this might be related to the incremental typechecking thing. This describes a problem when you try to fill in a table directly inside of the constructor instead of filling the properties with dot operator, the autofill breaks for half of the fields, but works for the other half arbitrarily
local t :{key1:boolean, thing2:CFrame, aaa3:vector} = {
ke... <- this autofills
th... <- sometimes this doesnt autofill
}
Hi! Thanks for sharing this - I saw your original example, and that sounds really frustrating, we definitely don’t want you to have to do the tedious thing just to get autofill. I don’t know the cause of this exactly, but I will file this as a bug and work on fixing it.
1 Like
How are recursive local functions created with this new type solver?
I’m getting type errors saying that function ‘f’ may be nil
See code for details
--!strict
--Recursive function that adds +1 until x==5
do
--Emits type error:
-- Value of type '((number) -> number)?' could be nil
local f; f = function(x:number):number
x += 1
if x < 5 then
x = f(x)
end
return x
end
print(f(1))--> 5
end
do
--This doesn't emit type errors,
--but apparently has a runtime performance hit because 'f' is no longer local
--(according to documentation)
function f(x:number):number
x += 1
if x < 5 then
x = f(x)
end
return x
end
print(f(1))--> 5
end
in the top your defining 2 variables called f, with only one of them being assigned
so the solver assumes f could be nil
Yes… but the old type solver would allow a variable to be assigned after declaration without issue, and now it always shows as possibly being nil, which is not favorable behavior.
You can’t even read the ‘nil’ value without it giving off a warning anyways, because then it says the value hasn’t been assigned yet.
You should be able to write:
local function f(x:number):number
x += 1
if x < 5 then
x = f(x)
end
return x
end
This will define f as a local function and expose it for recursion. We are still working on ironing out data flow issues like the one you cited. It should be possible to recognize that between local f and f = ... that f is no longer nil 
Wow… I could’ve sworn this threw a runtime error with local functions years ago. 
I have filed a bug report with the behavior I was having issues with though so it’ll be tracked.
Anyways, my bad
I am wondering … is this a bug or was it never supposed to work like this?
type SpawnClass = {
type: "SpawnClass",
name: string
}
type SpawnModel = {
type: "SpawnModel",
name: string,
id: string,
vehicleType: string
}
type SpawnTypes = SpawnClass | SpawnModel
local spawnModel = {} :: SpawnTypes & { type: "SpawnModel" }
spawnModel. -- expected to return the SpawnModel type (see image bellow)
Side Info: --! strict makes no change; putting { type: "SpawnModel" } in front of the SpawnTypes just switches the “type” value but that’s it, properties of SpawnModel are not actually present.
I can see a lot of potential if this would be fixed, thanks.