Luau Recap: July 2024

[weakroblox35]

@WheretIB

Lastly, if you have open-source or even private projects on GitHub which use Luau, you might be happy to learn that Luau now has official support on GitHub for .luau file extension.

This is huge for roblox, now only for a wikipedia article to be made or even blog posts discussing the language. (w3schools too?)

[roalex2008 (Dottik)]

The moment Luau allows me to add type constraints to generic functions, that is the day I will never ever disable strict again.

I’d love to do something like a basic interface, and then do composition just based on the type signature alone, not depending on any metamethods.

Something like this (C#)

public interface ITestTestable {
   public string GetTestableName();
}
public class Test {
    public static void RunTest<T>(T value) where T : ITestTestable {
        var name = value.GetTestableName(); // Legal code.
        System.Console.WriteLine($"Testable name: {name}"); 
    }
}

would be perfect in Luau to allow us to define a sort of OOP without the inherent costs of metatables.

-- Purely theoretical.
type IGun = { GetBulletCount: (self: IGun) -> number, ToggleDebugFeatures: (self: IGun, enable: boolean) -> () }
type IEnemy = { GetHealth: (self: IEnemy) -> number }

local function TestGun<T: & IGun, U: & IEnemy>(gun: T, target: U)
            if gun.GetBulletCount() > 20 then
                    warn("Weapon has 20 bullets")
            end
end

type Pistol = { PerformValidation: (self: Pistol) -> () } & IGun
type Zombie = { PlayGroan: (self: Zombie) -> () } & IEnemy

local pistol = nil :: Pistol
local zombie = nil :: Zombie
TestGun(pistol, zombie)

If this ever comes to be, I’d actively consider making types for all my Luau projects, no questions asked, because then I can be guaranteed generics won’t be pretty much taking any with extra steps, which is practically what it is, except on some cases, where you specify the generic type on types that use types that use generics.

[Pokemoncraft5290 (Based)]

@weakroblox35

now only for a wikipedia article to be made

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.

[Dekkonot]

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.

[icymanred (gengar)]

im pretty sure on ios only web browsers are allowed to do that stuff

[gillern]

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

[MrChickenRocket]

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?

[WheretIB]

@Tomi1231

The typechecking engine doesn’t allow this kind of structure, where I have 1 function make a table, and a second function adding stuff to it. The type inference engine seems to lock the type of that table.

Yes, we seal the tables returned from a function. This will be true in the new type checker as well.

@Tomi1231

The typechecking engine currently doesn’t allow for overwriting the type of a variable.

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.

@Tomi1231

It is also very annoying when dealing with numbers. In this example, the function is guaranteed to return 2 models, however, the type doesn’t reflect that. Just like with strings, where we are able to use specific strings (in tables and for variables with “Name1”|“Name2”), it would be very useful to use specific numbers (as shown with the comment in the example, or also with 1|2)

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.

@Tomi1231

Even more useful would be being able to assign a number range type, and maybe an integer type or unsigned integer, …

There are no plans to have this in the type system.

@Tomi1231

Moreover, as a bonus, it would be very useful to have an easy way to verify that the types being passed to a function are valid, and have it throw an error if not.

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

[WheretIB]

@PeZsmistic

Did you guys ever explain if native will ever work on the client?

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.

[WheretIB]

@nothing_1649

i’m having issues with leading bar and autoindent not working with eachother, any type with a leading bar separated by a newline goes from this:

…to this after hitting format document

I’ve notified the team, but feel free to submit an official Bug Report for better tracking of the fix progress.

@roalex2008

The moment Luau allows me to add type constraints to generic functions, that is the day I will never ever disable strict again.

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

@gillern

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

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.

[WheretIB]

@MrChickenRocket

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?

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.

[amets_iratxo (iratxo)]

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!

[Bam_Sori]

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)

[CarefreeCarrot]

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

[weakroblox35]

@WheretIB

This is the first attribute to become available and we are working on the ability to mark functions as deprecated using the @deprecated attribute. More on that here .

wait this is actually very nice?? no more warn({x} is deprecated please use {y})??.

[Computer_squad156 (DevComp)]

Super cool update, and also pretty excited for the upcoming typesolver!

[nothing_1649 (gom_a)]

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

[unixtensor (Kamp)]

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"

[icymanred (gengar)]

why would you want that? it looks ugly as hell

[drewbluewasabi (Drew)]

Most good type systems do