Luau Recap: July 2023

Hi Creators,

The Roblox Luau team is busy working on large updates coming in the near future, but just like last time, we have some new improvements that you can start using today.

Let’s get to it!

Analysis improvements

Indexing table intersections using x["prop"] syntax has been fixed and no longer reports a false positive error:

--!strict
type T = { foo: string } & { bar: number }

local x: T = { foo = "1", bar = 2 }

local y = x["bar"] -- This is no longer an error

Generic T... type is now convertible to ...any variadic parameter.

This solves issues people had with variadic functions and variadic argument:

--!strict
local function foo(...: any)
    print(...)
end

local function bar<T...>(...: T...)
    foo(...) -- This is no longer an error
end

We have also improved our general typechecking performance by ~17% and by additional ~30% in modules with complex types.

Other fixes include:

  • Fixed issue with type T? not being convertible to T | T or T? which could’ve generated confusing errors
  • Return type of os.date is now inferred as DateTypeResult when argument is “*t” or “!*t”

Runtime improvements

Out-of-memory exception handling has been improved. xpcall handlers will now actually be called with a “not enough memory” string and whatever string/object they return will be correctly propagated.

Other runtime improvements we’ve made:

  • Performance of table.sort was improved further. It now guarantees N*log(N) time complexity in the worst case
  • Performance of table.concat was improved by ~5-7%
  • Performance of math.noise was improved by ~30%
  • Inlining of functions is now possible even when they used to compute their own arguments
  • Improved logic for determining whether inlining a function or unrolling a loop is profitable

Autocomplete improvements

An issue with exported types not being suggested is now fixed.

Debugger improvements

We have fixed the search for the closest executable breakpoint line.

Previously, breakpoints might have been skipped in else blocks at the end of a function. This simplified example shows the issue:

local function foo(isIt)
    if isIt then
        print("yes")
    else
        -- When 'true' block exits the function, breakpoint couldn't be placed here
        print("no")
    end
end

This is all for now, and as always, we would like to thank the community for all the open-source contributions to Luau on GitHub!

131 Likes

This topic was automatically opened after 10 minutes.

looking forward to more Laua improvements in the future :slight_smile:

24 Likes

Good improvements :+1:

Any hints on what the large updates include :thinking:

19 Likes

Great to see all these changes! Looking forward to the bright future ahead.

19 Likes

Great improvements! Can’t wait to see what’s next for luau!

18 Likes

Kind of out of the loop when it comes to Luau updates but looking back I’m really impressed with all the new and super helpful features and improvements added in the recent months. I can’t wait to see what the Luau team is cooking for the future updates!

15 Likes

Thank you for the performance improvement! Quick question can there be any section on the dev-forum so we can request Luau features so we don’t have to go to GitHub.

14 Likes

I am really excited about the future of luau! I think the language has reached a point where it can certainty continue to exist outside the scope of roblox.

I know there’s an entire process and whatnot for features, but one thing I miss from typescript is numeric literals, which I think in roblox development would be extremely nice. Somebody would probably have to make a post on the github but I figure there might be some reason you guys aren’t interested?

14 Likes

I made a pull request on math.tau and it still isn’t added even though the entire luau community wants it

18 Likes

They can still be requested in Feature Requests section. GitHub does directly go to Luau team, so response time is better, but it’s only for built-in library requests like table and not for stuff like CFrame.

There will be a response posted for the ‘Severely lacking common library primitives/functionality’ topic.

14 Likes

Thanks for the reply! Because sometimes other users communicate that the dev-forum is not the right place for requesting features for Luau, which confuses me as Roblox is still its top user.

Thank you once again!

14 Likes

Recently I’ve been running into issues such as types seemingly not being recognized.

Here is an example of my problem:

--!strict

type State = "Standing"|"Running"
type StateInfoTable = {[State]:{Value1:number, Value2:number}}

local StateInfo:StateInfoTable = {
	Standing = {Value1 = 10}, --No warnings even though 'Value2' is not present | No autofill
	["Standing"::State] = {Value1 = 10}, --Warnings due to 'Value2' not being defined | Proper autofill
}

It seems I have to manually define what type the index is?

Is this a known issue?

19 Likes

We discussed this when adding string literals to the type system, and at that moment concluded that there’s odd semantical issues with numbers around NaN that make this a little less useful, and for most cases of idiomatic code we’d like to see code use string literals instead of number literals anyway - iow the section “error catching and control flow” in your post should probably be using strings or booleans.

The one exception to this is what we sometimes refer to as “tuple tables” - a table of a fixed length that has different types for different indices (“finite table” section in your post). We don’t support it right now. We want to eventually support it, but notably this is not the same as supporting numeric literals, and wouldn’t “naturally” fall out of supporting numeric literals in the type system.

14 Likes

Who else thinks reading the updates from Roblox is fun?

I wish there were more updates like this.

16 Likes

Can you please fix that annoying typechecking bug where it says that it expects a table type when you do this:

local Something: BasePart | Decal = nanana

Something.Transparency = 1

This has really been bugging me lately.

Thanks in advance! :slight_smile:

11 Likes

Hilarious you mention this right when I went on to this post to make a comment about this. It’s mildly annoying when you write something and you index similarly to tables and the type checking marks you on it. Maybe my coding habits are terrible and the type checker is telling me what not to do.

Some example:
image

14 Likes

Very nice improvements.

Is there any way these false cyclic dependency warnings will be fixed at any point?

6 Likes

I refuse to believe that our habits are wrong. The type checker should just adapt to how we do it. For as of now, I see it as a bug.

10 Likes

Hi, so using type checking improves the actual performance of code?

6 Likes