Now that’s a quality update, thank you guys for this amazing update!
1 Like
This hasn’t shipped yet; once it will ship require will automatically import types but the import is namespaced, that is
local Foo = require(path.to.module)
Will make it possible to refer to types in that module as Foo.Bar. And, importantly, will actually mean that the Foo table itself has a correct type so that we can typecheck access to that table and use of the functions declared within it.
6 Likes
Super excited with all the work being done on Luau. It’s fun watching a language be adopted for Roblox’s specific use-cases and challenges.
I, and many other developers, do some things to require by name instead of direct path, sort of like how npm modules load by name. This has never been directly kosher, but it really helps simplify refactoring codebases.
Is there anything on the roadmap to provide to Roblox Studio how these modules are resolved, or should we expect this sort of different resolution system to never be supported? Does Roblox have a new module resolution system in mind besides direct pathing?
8 Likes
All I meant that it is used in a lot of other languages and it would be nice to see it in luau too.
1 Like
Coincidentally we’re starting to look into this. It’s not part of the type system related efforts per se - but of course whatever we do here would have to be supported by the type system as well.
7 Likes
Personally, despite making code faster, I think Luau goes against the idea that Lua should be simple to use and read. Its nasty to read imho.
1 Like
It’s literally the same. The only way to “complicate” it is to optionally enable strict mode. For 99% of people you won’t be able to tell the difference when coding lua.
8 Likes
With the type checking beta, are threads and userdata going to be supported?
Static analysis for typeof appears to be missing PluginDrag, PathWaypoint, and the new RaycastParams and RaycastResult.
-- bad
type a = b
type b = a
-- ok
type a = {[b]:b}
type b = {[a]:a}
-- bad
type a = (b) => b
type b = (a) => a
Is it only supposed to work with tables? Similar thing when X self references, it works in tables but not in functions.
-- bad
type a = a
-- ok
type a = {[a]:a]}
-- bad
type a = (a) => a
Will variadics be supported?
local function f(...:number) => number
local result:number = 0
for i:number=1,select("#",...) do
result = result + select(i,...)
end
return result
end
Also, some warnings are pretty weird.
type T<t> = T<t>
local x:T<number> = 1
2 Likes
Can continue be highlighted the same way break is?
9 Likes
Does loadstring() support all these new features?
Could one load type annotated code in it?
3 Likes
continue is big. I was just looking to make a workaround for it earlier today, so this is pretty great.
2 Likes
We haven’t implemented thread support yet. userdata doesn’t seem to be super valuable since the only way to produce generic userdata is through newproxy - we do differentiate between Roblox userdata types.
Thanks, we’ll fix this.
Yeah I think right now the cycle is supposed to be in the table types; I don’t think you can make two corecursive functions without the types growing infinitely large.
We didn’t get to this yet but this came up today… hopefully? 
4 Likes
Eventually type annotations will work everywhere; right now they work in Studio if you enable the beta option, but they should work in loadstring context as well as regular script execution contexts.
3 Likes
What is the behavior for combining intersections and unions?
type t<a,b,c> = a&b|c
local var:t<number,string,string> = ""
That produces an error, however this appears to not error and produces a warning
type AND<a,b> = a&b
type t<a,b,c> = AND<a,b>|c
local var:t<number,string,string> = ""
1 Like
Nice update…
But ‘fubar’ is misspelled here.
1 Like
I would hope we could get support for classes in luau.
1 Like
@zeuxcg Is there any chance we could get “lightweight tables” in Luau? All members could be read-only, with no metatables. This would really help your idea of making ergonomic code fast.
For example, I might want to do:
local Services = {
Lighting = game:GetService("Lighting"),
Workspace = game:GetService("Workspace"),
}
I don’t want or need a “table access” penalty every time I access “Services.Workspace”, this could be optimized away in the backend. I never want to modify this table after definition. This would come in handy with many situations.
(Another example would be configuration tables for “constants”, or module import tables, et cetera).
1 Like
Luau should optimize generated code, like inlining once-used primitives or removing unused locals.
1 Like
You might be interested in records (https://www.youtube.com/watch?v=vScM-nk5Avk). But also table access is really fast in Luau.
We could optimize code similar to what you wrote automatically but it’s challenging to do across module boundaries which is where the real power of such optimizations hides.
Both are on the list yeah.
1 Like
Foo and Bar are common placeholder names; nothing is misspelled here.
1 Like