Vectors & typechecker?

[petrihakkinen]

I'm trying to register variables/functions with vector types for the typechecker, but primitive vector types seem to be missing. For example, they are not in SingletonTypes or TypeChecker where numberType, stringType, booleanType are. How can I register variables and functions that use vectors?

[zeux]

https://github.com/Roblox/luau/blob/master/fuzz/proto.cpp#L101-L115 has a basic example (note that it omits other metamethods for simplicity); from the type checkers perspective right now vector isn't a primitive type (we mostly didn't have to change this when introducing a new primitive type, but also type checker currently may not always respect metatable __index so replacing this with a primitive type may require further work inside the type checker).

[petrihakkinen]

I see. Thanks for the answer!

Should I create an issue for adding vectors as primitive type? If I understood correctly it's not possible to currently typecheck vectors without native side code changes, which could be problematic.

[petrihakkinen]

Hmm... I realized one complication could be that users may want to implement their own metamethods for vectors, but I wonder how feasible that is in practice because those metamethods will be much slower than the native ops implemented in the VM... But I guess it should be possible to overwrite a built-in typechecker type definition for vectors if needed, right?

[petrihakkinen]

Okay, I got typechecking for vectors working but I have a follow up question. We're using lightuserdata for opaque handles to certain objects which are not managed by Lua. How should I represent them to the typechecker? The closest match I can find are sealed tables with no fields but I'm not sure if that is the right way to go...

Oh, and we actually have a couple of different kinds of lightuserdata handles, so ideally we would like to have different types for each (from typechecker's POV). This also points towards sealed tables. Is this the intended way?

(This leads to other interesting topics: last year we discussed the possibility of having different kinds of user specified cheap lightuserdata objects which would be stored as tagged-values. Opaque handles would be a good use case for that feature. We could detect mismatched handles at runtime. But maybe this should be discussed under a different topic at some point.)

[zeux]

For opaque objects, we used to use sealed tables at Roblox but since switched to ClassTypeVars; the latter is likely a better fit because it's using nominal typing, meaning two ClassTypeVars aren't convertible to each other even if they have the same shape, which is likely what you want if you want multiple different lightuserdata types from the type checker perspective. The example I linked uses them for Vector3s but of course you don't have to even declare a metatable or members if you simply want an opaque handle.

[petrihakkinen]

Thanks! I'll go with ClassTypeVars.