Luau Recap: July 2024

Updates Announcements
#44

Love it. I have no complaints.

Hina the Seal

I LOVE HIM!!!

5 Likes
#45
4 Likes
#46

Jolly gosh, batman. Looks like we have a new mascot to play with. Isnā€™t he the cutest?

ā€¦ Iā€™m batman.

3 Likes
#47

Adorable mascot, despite what @RickAstll3y says. Itā€™s really great to see the language being pushed forward to newer and better heights, I hope the whole team knows we all appreciate it greatly!

5 Likes
#48

Really need native code gen for client. Iā€™m always doing intensive computational work with EditableImages and processing all those pixels with native code gen gives more than double the performance!

2 Likes
#49

There were talks about this quite a bit here and in the OSS discord. TLDR; this isnā€™t something Luau is looking to implement anytime soon.

This isnā€™t something which feels very ā€œLuau-likeā€. Luauā€™s type system excels at being dead simple to grasp, while also allowing for gradually typed code. I really do like how Luau types donā€™t overshadow the underlying code logic, which types in TypeScript often do. If youā€™re looking to have some of the specific features like type constraints, those are currently being worked on as part of a new type solver.

Here are some RFCs being worked on (they donā€™t currently exist in stable Luau) that you might find interesting:

As for type-constraints, there was a proposal made and the team definitely wants to implement them at some point.

2 Likes
#50

image

Iā€™m trying to create a recursive tree of functions that gets called depending on the context of the functions before it. The generic is for a stored variable that should be passed when calling the function.

I understand this is a case of Recursive type being used with different parameters, but Iā€™m not sure why thatā€™s an issue. I understand the most typical case of recursive calls maintains the same type parameters, but I donā€™t see why in strict mode all of them have to.

Edit - My case is a variant of BehaviorTree / FiniteStateMachine - whereas normally you could
modify it using some sort of format:

local function doAction(args) --Prepare Modified Action
    return function(blackboard)
        --On Action Call
    end
end

and this would remove the need for the generic altogether, Iā€™m also passing an internal blackboard sort of structure and had been hoping to reduce the number of function calls / make creating actions simpler by making it:

local function doAction(blackboard, args)
    -- On Action Call
end

Since Iā€™m going to be making a large number of actions.

1 Like
#51

The problem weā€™re trying to avoid is one where the full expansion of a type could potentially be infinite. For example:

type Weird<a> = { data: a, children: Weird<{a}> }

You can read a more detailed description here: rfcs/docs/recursive-type-restriction.md at master Ā· luau-lang/rfcs Ā· GitHub

Weā€™d like to lift this restriction someday, but itā€™s not trivial to do.