This topic was automatically opened after 16 minutes.
Luau open source confirmed?
To be honest, an open-source version of Luau would be amazing. I already love the language and bringing it to a non-Roblox environment is useful for developers like me who also like to write backend code that works with Roblox APIs. Soon all my Roblox stuff can be done in a single language.
Honestly, that new logo could use some work. I’m not getting any Roblox vibes from it. There’s no gradient or box in the middle.
Was the U supposed to be lowercased? But yeah It looks good lol!
ROBLOX IS LISTENING!
What will these “better tools” look like, and when can we expect to see these released. Since i think many of us on the forums have expressed our concern about the current tools for memory analysis on roblox will this finally quench our thirst?
The u is intended to be lowercased since Luau is meant to be pronounced the same way as the Hawaiian lūʻau (also spelled luau) AFAIK.
thanks for the PascalCas’ed
Time to switch all instances of table[#table+1]=value in my code to use table.insert now
Nevertheless, this is a nice change and will definitely make it easier to write easy-to-read code while still maintaining performance!
Time to update some code! This is great, especially when dealing with large arrays of data.
It’s great to keep seeing improvements being squeezed out built-ins, can’t wait to see what’s in store for the future.
Luau looks really confusing on these screenshots
will old games break because of this script update?
Luau is additive: It only adds additional features to the language. Your normal Lua code will continue to work like it did before if you choose not to use the additional Luau features.
Here is what I think the Luau logo should be:
So it looks more similar to the Studio logo
The Luau Type Checker doesn’t change anything when running the code, it’s a script editor system. It does enhance performance however.
--!strict
local function add(a: number, b: number) : number
return a + b
end
add("hey", 5) -- warning
Oh ok, I thought it would change something when running code as well, thanks for telling me!
I tried using generic functions and typed variadics, but this seems to generate a warning? It looks like it should work, since it returns all values and T...
should be (number,number)
.
--!strict
local function f<T...>(...:T...):T...
return ...
end
local a,b = f(1,2)
-- W000: (5,1) Function only returns 0 values. 2 are required here
This also doesn’t seem to work.
--!strict
local function f<T...>(...:T...):...any
return ...
end
-- W000: (3,2) Failed to unify variadic packs
Shouldn’t everything be ok for ...any
(any amount of values with any types)?
Am I doing something wrong in these examples, or are these bugs?
You are trying to use generic variadics that aren’t quite ready. The syntax you use means “T… refers to a tuple of types that don’t have to be the same”. Some bugs in this area will be fixed in the coming weeks with a proper announcement next month, as well as better error messages.
You can, however, do this today:
local function f<T>(...:T): ...T
return ...
end
Which means that f() takes any number of values of the same type and returns all of them.
Finally! All the code I’ve written using table.insert(t, v)
is no longer inferior!