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
since when code editor started to recognise type function declaration?
Would there be dedicated autocompletion for these in the future (considering there’s no types singleton autocompletion and autocompletion for arguments)?
It looks like quite powerful tool if you can use it.
Will we be able to also put constraints on generic types?
Sorry, i replied on your comment accidentally, just wanted to report these
all these bugs are minor but they should really be fixed! I love the new type functions but if these dont get fixed its really hard to work with the strict mode
would be nice if we didnt have to specify self like this. This is general case so its not even OOP, its the same with tables like this:
heres another example of an error, it says that the Trove does not have a destroy field, which it doesnt (unless you consider the metatable), this shouldnt be an error because the field exists, its just in the metatable.
1 Like
Shared self should fix your first issue, its just not implemented yet.
Bounded polymorphic types is the proper name for “constraints on generic types,” so, yeah, that’s exactly what I was trying to say! 
This is causing bugs to appear about 20 warnings to appear in my script analysis when I turn this on. My scripts are working fine and are not using deprecated functions. When it’s off there is no warnings.