For some reason I no longer get autocompletion after enabling the “New Luau type solver” beta feature, is there anything I need to do to get it working again?
Not sure if it is possible now but it’d be nice to be able to get an automcomplete in cases like this (very simplified, usually theres a bit more going on)
instead of having to specify it as a typeof({}) which i feel is a bit weird. (unless the table is specifically frozen, with table.freeze, i feel this should happen because its kind of untrue to whats actually going to happen)
i dont get any autocompletion anymore after enabling this beta. what gives? setting the “self” variable used to be so reliable, but now the self variable’s type is no longer recognized. neither do if statements work, checking for parts in the player character is worse now as every type is “unknown”
keyof has made using Luau so much more enjoyable omg 
4 Likes
Using the new Type solver has a strange issue, in the which it seems the first line of EVERY script that has any form of type checking(unless using typeof/type/:IsA()) has a warning, it doesn’t matter what’s there, it could just be whitespace, and it’d still have a warning on line 1
not done a huge amount of testing, but I’ve confirmed it’s because of the new type solver.
(also there’s a topic about it from someone else : Weird line on the first line of every script)
2 Likes
Is it now possible to create dynamic parameter types based on previous arguments?
Similar to something mentioned in this post:
I’ve tried seeing if I could make dynamic parameter types but I haven’t found a working solution yet.
EDIT:
Something like this sorta works? Although it won’t pick the type of the second argument. It’ll only list out all the possible arguments.
type Args = {
Confetti: { Position: Vector3 },
Explosion: { Radius: number }
}
type ExampleFunc<T = keyof<Args>> = (effect: T, args: index<Args, T>) -> ()
The warning on the first line occurs whenever constraint solving (the mechanism by which the new type solver’s type inference system works) fails to complete. So, scripts in which that’s happening are reflections of one or more bugs in the new type solver that we’re working to fix, but the warning is there with a description to provide context to the user: the other errors you’re seeing in this script may be completely nonsensical because type inference broke down. We’re working hard to fix these bugs before the general release of the new type solver, but you can feel free to open devforum bug reports or GitHub issues with any small reproductions you can of this warning, and those will be helpful to us in working through the bugs.
1 Like
If you only want to do this based on the type of the earlier parameter, this is possible with overloaded functions which can be defined using intersection types, e.g.
type Overloaded =
& (number, string) -> number
& (boolean, number) -> number
& (string, string) -> string
The type system will match the argument types at the call sites against a particular overload, and select one that’s right (and select the “closest” one(s) if none are right, to report an error based on that).
If you want the type of a parameter to depend on the value provided to an earlier type, however, this is not possible in Luau today regardless of which type solver you’re using. The name for that feature is “dependent typing” generally, and it’s a very advanced type system feature (with extremely undecidable inference) that is seen in essentially no mainstream programming language. If you want to see some of the languages that do have it, you can check out Agda, Idris, or Roqc. Designing a type inference scheme that is highly usable (a direct goal of Luau as a project) for a programming language that supports dependent typing is an area of active research in the field, and would be even more ambitious than Luau already is.
3 Likes
function Util.ExecuteOnEqualValue<X>(object: ValueObject<X>, value: X, execute: (X) -> ())
object:GetPropertyChangedSignal("Value"):Connect(function()
if value == object.Value then
execute(value)
end
end)
end
export type ValueObject<X = any> = ValueBase & {Value: X}
This block of code shows a warning:
Not sure if this is a bug, but it breaks on the function.
Error:
Type function instance t1 where t1 = union<number, add<mod<t1, number>, number>> is uninhabited This is likely to be a bug, please report it at https://github.com/luau-lang/luau/issues
The code
–!strict
local a = 4
local b = 2
local function func():number
local new = (a % b) + 1
a = new
return new
end
1 Like
Can I suggest a feature for parameters on generic types. Even though this is irrelevant, it would be nice to have parametric polymorphism, and bounded parametric polymorphism in luau.
Hello, It seems there’s no detection when you have typo’s on this new solver. Sometimes I miss spelled or didn’t follow the actual letter-case of a variable name.
Like this:
local hello = "Hi"
print(Hello)
And I have no idea if i typed it correctly without glancing at it once more. Its very hard to find the typo if I have a huge code. The only way to know is running it at run-time and getting bombarded with typo errors.
It’s preventing me from switching to this new solver. Old solver detects this.
Just to confirm: you’re experiencing this issue in non-strict mode, right?
1 Like
Luau already has parametric polymorphism, but bounded polymorphic types is on the roadmap since it’s necessary for being able to use type functions to deal with overloaded operators in full generality.
1 Like
Yes, I am in non-strict mode. usually I don’t work with strict mode.
I have been having issues recently, with or without the new type solver beta enabled.
This should autocomplete when typing Error but it doesn’t;
This gives an error when you use ‘strict’ mode;
I don’t know when this started happening but it has been causing me grief. I was able to do this before it wouldn’t give me errors when trying to add extra properties to a table value that was returned by a function
have this bug here,
function SpatialHash:GetPartsAtPosition(Position : Vector3) : {BasePart}
local RefGrid = self.Grid
local Hash1, Hash2 = self:Hash(Position), self:Hash(Position+Vector3.one/2)
local H1 = RefGrid[Hash1]
local H2 = RefGrid[Hash2]
if Hash1 ~= Hash2 and H2 then
local Clone = table.create(#H1+#H2);
for _, Other in H2 do
table.insert(Clone, Other)
end
for _, Other in H1 do
table.insert(Clone, Other)
end
return Clone
end
return H1;
end
not sure why table.create says it returns 0 values.
heres the exact type error too.
Trying to do something like this, but there is no way to refine the type of a generic (no TypeScript ‘extends!’). Is this currently possible?
There also seems to be a silly schrodinger’s autocomplete bug happening here.
You can extend currently by using &, but make sure in returns to have it be only the generic thats returned and not T & {}
local function meow<T>(t: T & {}): T
...
end