Ehhh, that probably won’t happen for a while until Luau spreads a bit further beyond Roblox, as Wikipedia has requirements of notability for an article.
My understanding based on discussions on Discord with the team is that there’s a resistance to bringing it to the client since there are platforms that don’t allow it. While they could enable it for e.g. PC clients, it would make the already significant performance difference even more severe.
Mind you, this is just the vibe I get and not an actual answer. I imagine the official corporate answer is “We are looking into opportunities to being native codegen to the Roblox client” with no followup.
im pretty sure on ios only web browsers are allowed to do that stuff
Not sure if this is your guys team but types are still not highlighted differently from variable names and so at a glance its hard to tell what is a variable and what is a type. Would be great if the types were a different color
Right now it’s difficult/impossible to tell if we’re hitting the fast path when a fast path is available.
Is it possible to get a flag similar to !native that will give us feedback on if we’re hitting the slow path?
Yes, we seal the tables returned from a function. This will be true in the new type checker as well.
This is something that will be fixed in the new type checker.
But be aware that there might be temporary bugs in the Beta that we plan to release.
This will not be included in the new type checker.
We are aware of some developers requesting this, but there is no plan to extend the type system this way.
There are no plans to have this in the type system.
There were a few feature requests for this before, we do not plan to implement this.
One of the recent ones was Allow optional enforcing of static typing in functions, methods, and variables
We are exploring options to bring native code generation on desktop clients.
We are aware that desktops are already more powerful and such a system has a bigger need on mobile platforms, but those often place artificial limitations on porting the system there.
While there is a risk to make the performance gap between mobile and desktop larger, we don’t want to artificially limit performance where it can be unlocked.
I’ve notified the team, but feel free to submit an official Bug Report for better tracking of the fix progress.
Luau subtyping rules allow just specifying the base type instead of having to constrain generics like in C#.
You can just say that function accepts interfaces which satisfy IGun/IEnemy and pass Pistol or Zombie.
We have an extension to the type system coming that will allow specifying read-only and write-only fields which will help describing these interfaces without getting false positive type conversion errors rfcs/docs/syntax-property-access-modifiers.md at 66e1e2a434f8969a6ddd4ace8f581ecade1ac4f6 · luau-lang/rfcs · GitHub
You can track the feature request for this here: Separate syntax highlighting color for type annotations
While it’s very sad how old the request is, we hope to implement it this year.
This is especially true for Vector3
type annotations where it’s impossible to tell if the compiler figured the type out or not.
We plan to have tooling in Studio to display that information after a playtest in the future.
The @checked
annotations are a feature we’re using to support the new non-strict mode in the new type solver that we’ve been working on. More information will come out about its meaning in future announcements, so stay tuned!
thx for wonderful updates :DD
Although it worked fine in VS Code,
requiring a large module from another script in Studio often returned an *error-type*
and couldn’t recognize some exported types, showing them only as ‘any’.
There weren’t any wrong types, but it returned *error-type*
This bug had been very annoying for several months
However, it was fixed after this Luau recap update
I don’t know why the bug occurred or how it was fixed, but I hope the bug doesn’t reappear
It was truly painful…
I was quite unsure of the cause, so I hesitated to write a bug report, but it has been fixed now.
Another
Additionally, there is another issue that only occurs in Roblox Studio, not in VS Code using the Luau LSP.
It seems that this issue is specific to Roblox Studio rather than Luau, so I’m writing it here instead of on the Luau GitHub bug reports.
from Release Note 601
When using union & or intersection | more than about 200 times in Lua, an orange line appears on the top line, and I can no longer export types or use auto-completion. All types become any.
This does not happen when using Luau LSP in VS Code.
I don’t know if there’s a type limit specific to Roblox Studio, but if there is, I hope it gets removed.
I need many union types because I want to implement a constructor function type like Instance.new("Class")->Class
.
e.g.
type Constructor<name = string, class = any> = (name: name)->(class)
type newFn =
& Constructor<"Part", Part>
& Constructor<"MeshPart", MeshPart>
& Constructor<"Decal", Decal>
& Constructor<"AnotherPart", {Another: boolean} & Part>
& Constructor<"CustomInstance", {Name: string, Age: number}>
& Constructor<"Humanoid", Humanoid>
local new: newFn
local meshPart = new("MeshPart")
local anotherPart = new("AnotherPart")
if anotherPart.Another then
-- ...
end
Imo Roblox Studio types should have as few limitations as possible, as long as they don’t cause syntax or structural issues (even if it affects performance due to the lack of count limits)
I don’t know if parameter function attributes would be able to replace function types with large union types.
but even if they could, It would be better if the limit on the number of types were removed to allow for the implementation of complex module types (if there is)
The github .luau syntax highlighting shows a distinct color for types
Why does roblox studio itself still not support distinct syntax highlighting for types? My eyes still have to struggle to pick out the parameters from the types in long functions
function a(num :number, cf :CFrame, ReallyLongParameterName :MyOwnCustomType)
ThisIsAnUpvalue:FactoryConstructorServiceHandlerMethod(param :ParamType)
end
wait this is actually very nice?? no more warn(
{x} is deprecated please use {y})
??.
Super cool update, and also pretty excited for the upcoming typesolver!
did you get “detected possibly infinite typepack growth” or something in script analysis? i got that for the first time when i was just screwing around with luau limits, i can’t remember how i triggered it but it was something like copying and pasting {} & {} & {} & {}
over and over again
i hadn’t seen it mentioned anywhere but it only goes away if you fix the issue and restart studio, judging by the message it seems to be a failsafe for if luau analysis completely breaks
I beg for an import
type global, I often run into module require recursion errors when im just requiring an exported type,
can only dream of one day that Luau’s type system can reach the levels of Rust’s algebraic type system or TypeScript’s type system where I could achieve shenanigans like this
type LastChar<T extends string> = `${T}` extends `${infer Front}${infer Back}` ? Back extends '' ? Front : LastChar<Back> : never
type OddNumbers = '1' | '3' | '5' | '7' | '9'
type IsOdd<T extends number> = LastChar<`${T}`> extends OddNumbers ? true : false
type IsOddOrEven<T extends number> = IsOdd<T> extends true ? "Odd" : "Even"
let N1: IsOddOrEven<5> = "Odd"
let N2: IsOddOrEven<2> = "Even"
let N3: IsOddOrEven<187521923> = "Odd"
why would you want that? it looks ugly as hell
Most good type systems do
Love it. I have no complaints.
I LOVE HIM!!!