Roblox luau

-
  Download Here --> https://tinyurl.com/rhf4x3dp    (Copy and Paste Link)






 Luau
Luau (lowercase u, /ˈlu.aʊ/) is a fast, small, safe, gradually typed embeddable scripting language derived from Lua.
Motivation
Around 2006, Roblox started using Lua 5.1 as a scripting language for games. Over the years we ended up substantially evolving the implementation and the language; to support growing sophistication of games on the Roblox platform, growing team sizes and large internal teams writing a lot of code for application/editor (1+MLOC as of 2020), we had to invest in performance, ease of use and language tooling, and introduce a gradual type system to the language. More…
Sandboxing
Luau limits the set of standard libraries exposed to the users and implements extra sandboxing features to be able to run unprivileged code (written by our game developers) side by side with privileged code (written by us). This results in an execution environment that is different from what is commonplace in Lua. More…
Compatibility
Whenever possible, Luau aims to be backwards-compatible with Lua 5.1 and at the same time to incorporate features from later revisions of Lua. However, Luau is not a full superset of later versions of Lua - we do not always agree with Lua design decisions, and have different use cases and constraints. All post-5.1 Lua features, along with their support status in Luau, are documented here.
Syntax
Luau is syntactically backwards-compatible with Lua 5.1 (code that is valid Lua 5.1 is also valid Luau); however, we have extended the language with a set of syntactical features that make the language more familiar and ergonomic. The syntax is described here.
Analysis
To make it easier to write correct code, Luau comes with a set of analysis tools that can surface common mistakes. These consist of a linter and a type checker, colloquially known as script analysis, and are integrated into luau-analyze command line executable. The linting passes are described here, and the type checking user guide can be found here.
Performance
In addition to a completely custom front end that implements parsing, linting and type checking, Luau runtime features new bytecode, interpreter and compiler that are heavily tuned for performance. Luau currently does not implement Just-In-Time compilation, but its interpreter can be competitive with LuaJIT interpreter depending on the program. We continue to optimize the runtime and rewrite portions of it to be even more efficient. While our overall goal is to minimize the amount of time programmers spend tuning performance, some details about the performance characteristics are provided for inquisitive minds.
Libraries
As a language, Luau is a full superset of Lua 5.1. As far as standard library is concerned, some functions had to be removed from the builtin libraries, and some functions had to be added; refer to full documentation for details. When Luau is embedded into an application, the scripts normally get access to extra library features that are application-specific.
Luau
Luau is an open-source dialect of Lua used by Roblox as a programming language for scripts. The source code of the language is available under the Expat license. Luau introduces gradual typing support and performance optimizations to Lua, and also aims for backward compatibility with Lua 5.1.
Contents
History
On August 27, 2019, Roblox would switch its scripting language to Luau. [1]
Since November 3, 2021, Luau is open source and the RFC process used to approve user-facing changes to the language and its core libraries is open to the public. [2]
Type checking
Luau supports gradual typing, which allows type checking for scripts. Type checking is on by default ( --!nonstrict ). Adding the comment --!strict in a script's source code enables full type checking, while the comment --!nocheck disables type checking completely for that script. Roblox supports classes and data types for type checking as well as module interactions. [3]
References

  ↑Kapoulkine, Arseny (2019, August 27). "Faster Lua VM Released". From DevForum. Accessed February 10, 2023. Archived from the original on December 17, 2022.
  ↑ (n.d.) . Luau Goes Open-Source. Accessed November 3, 2021. Archived from the original on November 3, 2021.
  ↑ (n.d.) . Type checking. Accessed February 10, 2023. Archived from the original on January 30, 2023.

External links
Type checking
Luau supports a gradual type system through the use of type annotations and type inference.
Type inference modes
There are three modes currently available. They must be annotated on the top few lines among the comments.
nocheck mode will simply not start the type inference engine whatsoever.
As for the other two, they are largely similar but with one important difference: in nonstrict mode, we infer any for most of the types if we couldn’t figure it out early enough. This means that given this snippet:
We can infer foo to be of type number , whereas the foo in the snippet below is inferred any :
However, given the second snippet in strict mode, the type checker would be able to infer number for foo .
Structural type system
Luau’s type system is structural by default, which is to say that we inspect the shape of two tables to see if they are similar enough. This was the obvious choice because Lua 5.1 is inherently structural.
type A = x: number, y: number, z: number?> type B = x: number, y: number, z: number> local a1: A = x = 1, y = 2> -- ok local b1: B = x = 1, y = 2, z = 3> -- ok local a2: A = b1 -- ok local b2: B = a1 -- not ok
Builtin types
Lua VM supports 8 primitive types: nil , string , number , boolean , table , function , thread , and userdata . Of these, table and function are not represented by name, but have their dedicated syntax as covered in this syntax document, and userdata is represented by concrete types; other types can be specified by their name.
The type checker also provides the builtin types unknown , never , and any .
local s = "foo" local n = 1 local b = true local t = coroutine.running() local a: any = 1 print(a.x) -- Type checker believes this to be ok, but crashes at runtime.
There’s a special case where we intentionally avoid inferring nil . It’s a good thing because it’s never useful for a local variable to always be nil , thereby permitting you to assign things to it for Luau to infer that instead.
unknown type
unknown is also said to be the top type, that is it’s a union of all types.
local a: unknown = "hello world!" local b: unknown = 5 local c: unknown = function() return 5 end
Unlike any , unknown will not allow itself to be used as a different type!
local function unknown(): unknown return if math.random() > 0.5 then "hello world!" else 5 end local a: string = unknown() -- not ok local b: number = unknown() -- not ok local c: string | number = unknown() -- not ok
In order to turn a variable of type unknown into a different type, you must apply type refinements on that variable.
local x = unknown() if typeof(x) == "number" then -- x : number end
never type
never is also said to be the bottom type, meaning there doesn’t exist a value that inhabits the type never . In fact, it is the dual of unknown . never is useful in many scenarios, and one such use case is when type refinements proves it impossible:
local x = unknown() if typeof(x) == "number" and typeof(x) == "string" then -- x : never end
any type
any is just like unknown , except that it allows itself to be used as an arbitrary type without further checks or annotations. Essentially, it’s an opt-out from the type system entirely.
local x: any = 5 local y: string = x -- no type errors here!
Function types
Let’s start with something simple.
local function f(x) return x end local a: number = f(1) -- ok local b: string = f("foo") -- ok local c: string = f(true) -- not ok
In strict mode, the inferred type of this function f is (A) -> A (take a look at generics), whereas in nonstrict we infer (any) -> any . We know this is true because f can take anything and then return that. If we used x with another concrete type, then we would end up inferring that.
Similarly, we can infer the types of the parameters with ease. By passing a parameter into anything that also has a type, we are saying “this and that has the same type.”
local function greetingsHelper(name: string) return "Hello, " .. name end local function greetings(name) return greetingsHelper(name) end print(greetings("Alexander")) -- ok print(greetings(name = "Alexander">)) -- not ok
Table types
From the type checker perspective, each table can be in one of three states. They are: unsealed table , sealed table , and generic table . This is intended to represent how the table’s type is allowed to change.
Unsealed tables
An unsealed table is a table which supports adding new properties, which updates the tables type. Unsealed tables are created using table literals. This is one way to accumulate knowledge of the shape of this table.
local t = x = 1> -- t.y = 2 -- t.z = 3 --
However, if this local were written as local t: = , it ends up sealing the table, so the two assignments henceforth will not be ok.
Furthermore, once we exit the scope where this unsealed table was created in, we seal it.
local function vec2(x, y) local t =  t.x = x t.y = y return t end local v2 = vec2(1, 2) v2.z = 3 -- not ok
Unsealed tables are exact in that any property of the table must be named by the type. Since Luau treats missing properties as having value nil , this means that we can treat an unsealed table which does not mention a property as if it mentioned the property, as long as that property is optional.
local t = x = 1> local u :  x : number, y : number? > = t -- ok because y is optional local v :  x : number, z : number > = t -- not ok because z is not optional
Sealed tables
A sealed table is a table that is now locked down. This occurs when the table type is spelled out explicitly via a type annotation, or if it is returned from a function.
local t :  x: number > = x = 1> t.y = 2 -- not ok
Sealed tables are inexact in that the table may have properties which are not mentioned in the type. As a result, sealed tables support width subtyping, which allows a table with more properties to be used as a table with fewer
type Point1D =  x : number > type Point2D =  x : number, y : number > local p : Point2D =  x = 5, y = 37 > local q : Point1D = p -- ok because Point2D has more properties than Point1D
Generic tables
This typically occurs when the symbol does not have any annotated types or were not inferred anything concrete. In this case, when you index on a parameter, you’re requesting that there is a table with a matching interface.
local function f(t) return t.x + t.y --^ --^ end f(x = 1, y = 2>) -- ok f(x = 1, y = 2, z = 3>) -- ok f(x = 1>) -- not ok
Table indexers
These are particularly useful for when your table is used similarly to an array.
local t = "Hello", "world!"> -- print(table.concat(t, ", "))
Luau supports a concise declaration for array-like tables, (for example, is equivalent to ); the more explicit definition of an indexer is still useful when the key isn’t a number, or when the table has other fields like .
Generics
The type inference engine was built from the ground up to recognize generics. A generic is simply a type parameter in which another type could be slotted in. It’s extremely useful because it allows the type inference engine to remember what the type actually is, unlike any .
type PairT> = first: T, second: T> local strings: Pairstring> = first="Hello", second="World"> local numbers: Pairnumber> = first=1, second=2>
Generic functions
As well as generic type aliases like Pair , Luau supports generic functions. These are functions that, as well as their regular data parameters, take type parameters. For example, a function which reverses an array is:
function reverse(a) local result =  for i = #a, 1, -1 do table.insert(result, a[i]) end return result end
The type of this function is that it can reverse an array, and return an array of the same type. Luau can infer this type, but if you want to be explicit, you can declare the type parameter T , for example:
function reverseT>(a: T>): T> local result: T> =  for i = #a, 1, -1 do table.insert(result, a[i]) end return result end
When a generic function is called, Luau infers type arguments, for example
local x: number> = reverse(1, 2, 3>) local y: string> = reverse("a", "b", "c">)
Generic types are used for built-in functions as well as user functions, for example the type of two-argument table.insert is:
Union types
A union type represents one of the types in this set. If you try to pass a union onto another thing that expects a more specific type, it will fail.
For example, what if this string | number was passed into something that expects number , but the passed in value was actually a string ?
local stringOrNumber: string | number = "foo" local onlyString: string = stringOrNumber -- not ok local onlyNumber: number = stringOrNumber -- not ok
Note: it’s impossible to be able to call a function if there are two or more function types in this union.
Intersection types
An intersection type represents all of the types in this set. It’s useful for two main things: to join multiple tables together, or to specify overloadable functions.
type XCoord = x: number> type YCoord = y: number> type ZCoord = z: number> type Vector2 = XCoord & YCoord type Vector3 = XCoord & YCoord & ZCoord local vec2: Vector2 = x = 1, y = 2> -- ok local vec3: Vector3 = x = 1, y = 2, z = 3> -- ok
type SimpleOverloadedFunction = ((string) -> number) & ((number) -> string) local f: SimpleOverloadedFunction local r1: number = f("foo") -- ok local r2: number = f(12345) -- not ok local r3: string = f("foo") -- not ok local r4: string = f(12345) -- ok
Note: it’s impossible to create an intersection type of some primitive types, e.g. string & number , or string & boolean , or other variations thereof.
Note: Luau still does not support user-defined overloaded functions. Some of Roblox and Lua 5.1 functions have different function signature, so inherently requires overloaded functions.
Singleton types (aka literal types)
Luau’s type system also supports singleton types, which means it’s a type that represents one single value at runtime. At this time, both string and booleans are representable in types.
We do not currently support numbers as types. For now, this is intentional.
local foo: "Foo" = "Foo" -- ok local bar: "Bar" = foo -- not ok local baz: string = foo -- ok local t: true = true -- ok local f: false = false -- ok
This happens all the time, especially through type refinements and is also incredibly useful when you want to enforce program invariants in the type system! See tagged unions for more information.
Variadic types
Luau permits assigning a type to the . variadic symbol like any other parameter:
local function f(. : number) end f(1, 2, 3) -- ok f(1, "string") -- not ok
f accepts any number of number values.
In type annotations, this is written as . T :
Type packs
Multiple function return values as well as the function variadic parameter use a type pack to represent a list of types.
When a type alias is defined, generic type pack parameters can be used after the type parameters:
type SignalT, U. > =  f: (T, U. ) -> (), data: T >
Keep in mind that . T is a variadic type pack (many elements of the same type T ), while U. is a generic type pack that can contain zero or more types and they don’t have to be the same.
It is also possible for a generic function to reference a generic type pack from the generics list:
local function callT, U. >(s: SignalT, U. >, . : U. ) s.f(s.data, . ) end
Generic types with type packs can be instantiated by providing a type pack:
local signal: Signalstring, (number, number, boolean)> = -- call(signal, 1, 2, false)
There are also other ways to instantiate types with generic type pack parameters:
type AT, U. > = (T) -> U. type B = Anumber, . string> -- with a variadic type pack type CS. > = Anumber, S. > -- with a generic type pack type D = Anumber, ()> -- with an empty type pack
Trailing type pack argument can also be provided without parentheses by specifying variadic type arguments:
type ListHead, Rest. > = (Head, Rest. ) -> () type B = Listnumber> -- Rest. is () type C = Listnumber, string, boolean> -- Rest is (string, boolean) type ReturnsT. > = () -> T. -- When there are no type parameters, the list can be left empty type D = Returns -- T. is ()
Type pack parameters are not limited to a single one, as many as required can be specified:
type CallbackArgs. , Rets. > =  f: (Args. ) -> Rets. > type A = Callback(number, string), . number>
Typing idiomatic OOP
One common pattern we see throughout Roblox is this OOP idiom. A downside with this pattern is that it does not automatically create a type binding for an instance of that class, so one has to write type Account = typeof(Account.new("", 0)) .
local Account =  Account.__index = Account function Account.new(name, balance) local self =  self.name = name self.balance = balance return setmetatable(self, Account) end function Account:deposit(credit) self.balance += credit end function Account:withdraw(debit) self.balance -= debit end local account: Account = Account.new("Alexander", 500) --^^^^^^^ not ok, 'Account' does not exist
Tagged unions
Tagged unions are just union types! In particular, they’re union types of tables where they have at least some common properties but the structure of the tables are different enough. Here’s one example:
type OkT> =  type: "ok", value: T > type ErrE> =  type: "err", error: E > type ResultT, E> = OkT> | ErrE>
This Result type can be discriminated by using type refinements on the property type , like so:
if result.type == "ok" then -- result is known to be Ok -- and attempting to index for error here will fail print(result.value) elseif result.type == "err" then -- result is known to be Err -- and attempting to index for value here will fail print(result.error) end
Which works out because value: T exists only when type is in actual fact "ok" , and error: E exists only when type is in actual fact "err" .
Type refinements
When we check the type of any lvalue (a global, a local, or a property), what we’re doing is we’re refining the type, hence “type refinement.” The support for this is arbitrarily complex, so go crazy!
Here are all the ways you can refine:

  Truthy test: if x then will refine x to be truthy.
  Type guards: if type(x) == "number" then will refine x to be number .
  Equality: x == "hello" will refine x to be a singleton type "hello" .

And they can be composed with many of and / or / not . not , just like ~= , will flip the resulting refinements, that is not x will refine x to be falsy.
local maybeString: string? = nil if maybeString then local onlyString: string = maybeString -- ok local onlyNil: nil = maybeString -- not ok end if not maybeString then local onlyString: string = maybeString -- not ok local onlyNil: nil = maybeString -- ok end
local stringOrNumber: string | number = "foo" if type(stringOrNumber) == "string" then local onlyString: string = stringOrNumber -- ok local onlyNumber: number = stringOrNumber -- not ok end if type(stringOrNumber) ~= "string" then local onlyString: string = stringOrNumber -- not ok local onlyNumber: number = stringOrNumber -- ok end
local myString: string = f() if myString == "hello" then local hello: "hello" = myString -- ok because it is absolutely "hello"! local copy: string = myString -- ok end
And as said earlier, we can compose as many of and / or / not as we wish with these refinements:
local function f(x: any, y: any) if (x == "hello" or x == "bye") and type(y) == "string" then -- x is of type "hello" | "bye" -- y is of type string end if not (x ~= "hi") then -- x is of type "hi" end end
assert can also be used to refine in all the same ways:
local stringOrNumber: string | number = "foo" assert(type(stringOrNumber) == "string") local onlyString: string = stringOrNumber -- ok local onlyNumber: number = stringOrNumber -- not ok
Type casts
Expressions may be typecast using :: . Typecasting is useful for specifying the type of an expression when the automatically inferred type is too generic.
For example, consider the following table constructor where the intent is to store a table of names:
local myTable = names = > table.insert(myTable.names, 42) -- Inserting a number ought to cause a type error, but doesn't
In order to specify the type of the names table a typecast may be used:
local myTable = names =  :: string>> table.insert(myTable.names, 42) -- not ok, invalid 'number' to 'string' conversion
A typecast itself is also type checked to ensure the conversion is made to a subtype of the expression’s type or any :
local numericValue = 1 local value = numericValue :: any -- ok, all expressions may be cast to 'any' local flag = numericValue :: boolean -- not ok, invalid 'number' to 'boolean' conversion
Roblox types
Roblox supports a rich set of classes and data types, documented here. All of them are readily available for the type checker to use by their name (e.g. Part or RaycastResult ).
When one type inherits from another type, the type checker models this relationship and allows to cast a subclass to the parent class implicitly, so you can pass a Part to a function that expects an Instance .
All enums are also available to use by their name as part of the Enum type library, e.g. local m: Enum.Material = part.Material .
Finally, we can automatically deduce what calls like Instance.new and game:GetService are supposed to return:
local part = Instance.new("Part") local basePart: BasePart = part
Note that many of these types provide some properties and methods in both lowerCase and UpperCase; the lowerCase variants are deprecated, and the type system will ask you to use the UpperCase variants instead.
Module interactions
Let’s say that we have two modules, Foo and Bar . Luau will try to resolve the paths if it can find any require in any scripts. In this case, when you say script.Parent.Bar , Luau will resolve it as: relative to this script, go to my parent and get that script named Bar.
-- Module Foo local Bar = require(script.Parent.Bar) local baz1: Bar.Baz = 1 -- not ok local baz2: Bar.Baz = "foo" -- ok print(Bar.Quux) -- ok print(Bar.FakeProperty) -- not ok Bar.NewProperty = true -- not ok
-- Module Bar export type Baz = string local module =  module.Quux = "Hello, world!" return module
There are some caveats here though. For instance, the require path must be resolvable statically, otherwise Luau cannot accurately type check it.
Cyclic module dependencies
Cyclic module dependencies can cause problems for the type checker. In order to break a module dependency cycle a typecast of the module to any may be used:
local myModule = require(MyModule) :: any