This is so ducking amazing, I LOVE ITTTTTTTTTTTTTTTT
6 Likes
Horrifying sight, especially in a game that had 0 before.
Jokes aside, I do not understand this type error.
That’s the only place
indice is used.
10 Likes
Try running a for loop with a table, now it requires an indexer to loop through it for some reason.
Do we have to use the index in order to do a for loop?
6 Likes
I had problems with indexing from a type of {}, because that correctly represents an empty table now, as opposed to an open one.
I just replaced the annotation to {unknown} or {[unknown]: unknown} and that solves it.
5 Likes
export type classData = {
constructor: (self: any, ...any) -> ()?,
destructor: (self: any) -> ()?,
Public: {[any]: any}?,
Private: {[any]: any}?,
Protected: {[any]: any}?,
Friend: {any}?
}
I have a table type like this, so I can’t exactly cast unknown to it, what should I do in this case?
5 Likes
I’m assuming the solver isn’t adding an indexer type-function to record table types, which is why you can’t iterate over your classData directly.
Band-aid solution would be to ascribe before iterating:
for Key, Value in Record :: {[string]: unknown} do
end
Otherwise, why can’t you just index the fields individually?
5 Likes
That’s what I did for now, but this solution is pretty much what I used to do in the old type solver, I thought these problems would get solved in the new one.
6 Likes
Is this intended behaviour or is it a bug with the new type solver?
6 Likes
Try using this:
key: index<typeof(PlayerData), keyof<typeof(PlayerData)>>
6 Likes
This is exactly the step forward Luau needs! It feels like it addresses some of the bigger practical barriers to using strict mode + type safety that currently exist. Great work to the whole team involved in designing and implementing these new features 
7 Likes
Here’s a code with the blocked-xxxx… error
Code
--!strict
local con: RBXScriptConnection?
local timeElapsed = 0
con = game:GetService("RunService").PostSimulation:Connect(function(dt: number)
timeElapsed += dt
if timeElapsed >= 5 then
con:Disconnect() -- *blocked*: typecheck error occurs here
con = nil
end
end)
5 Likes
i was concerned about this being released too early, while i know this is a beta it just doesn’t feel ready yet however i feel like this’ll be leagues better than old solver once it’s resolved
i will probably adjust to try using the new solver since i was looking forward to keyof and type functions but jesus christ that’s a lot of weird errors
7 Likes
Sounds great, but in my project turning this on just has the effect of disabling all linting/typechecking/intellisense globally. It’s not an issue in the template projects so I know it’s not my app configuration. Any idea why this might happen?
5 Likes
i’ve had this issue before, it was caused by the type solver completely breaking down in a single script which took down script analysis for everything; i had to go figure out which script was causing it to blow up
7 Likes
I think I’ll just wait for the fix lol
8 Likes
You should report it here, I did the same thing.
4 Likes
Oh this is super neat, does this now also fix issues like Luau thinking that a variable will be nil when it probably won’t be?
I’ve had cases where doing this…
local zombie = game.ReplicatedService.entities.Zombie:Clone()
zombie.Parent = workspace
local torso : BasePart = zombie.Torso -- Warning at this line.
So sometimes, if you cloned a model and then tried to reference a part inside the model’s clone, it will sometimes give a warning because it doesn’t know if the object you’re referencing will exist in the model you cloned for instance (I could be wrong).
There’s some other scenarios where this also happens but I don’t remember from the top of my mind.
I think this was one too?
local part : BasePart? = workspace:FindFirstChild("Part")
if not part then return end
part.Color = Color3.new(1, 0, 0) -- Warning
This sometimes warned me that “part” could be nil, a bit inconvenient and annoying.
local part : BasePart? = workspace:FindFirstChild("Part")
if not part then
part.Color = Color3.new(1, 0, 0) -- Okay
end
But this is okay, as expected.
I however use the former method a lot because it makes code easier to read.
I’ve looked all over the place to find a way to tell the checker “Trust me, it will be there”.
3 Likes
Yeah, unfortunately the unacceptable performance issues in some cases mentioned in the original post amount to those features not working since they depend on type inference completing before they can provide an answer. We have an ongoing project right now that we expect to dramatically improve performance and improve error quality by reducing the excessive size of some types, but we’ve been working for a long time on the new solver and we want to be able to get it in the hands of users, even if we knew some folks were going to run into these performance issues.
10 Likes