Script Editor: Luau-Powered Autocomplete & Language Features Beta
Hi developers,
You (auto) complete us! Today we’re excited to announce a beta of our new Luau-powered autocomplete. Code completions will now be more comprehensive, more accurate, and more performant enabling you to code faster than ever before. Please see below for a breakdown of new functionality you should expect to work and a few things that are not implemented yet.
The beta can be enabled by toggling Studio > Beta Features > Luau-Powered Autocomplete.
New Features
Function parameters for functions in current script
Autocomplete will now give type-aligned completions for annotated function parameters. In the example below, autocomplete recognizes parameter ‘s’ as a string, and offers corresponding completions.
function abc(s:string)
s...
end
| Current | New |
|---|---|
 |
 |
Nested variables and functions
Completions will now be given for variables nested within functions, regardless of possible indirection. In the below example autocomplete recognizes that P refers to a function that returns ‘x’ and ‘y’, and suggests completions for the two variables.
function origin()
return {x = 0, y = 0}
end
local P = origin()
print(P...
| Current | New |
|---|---|
 |
 |
Context-aware keywords
When you begin a new expression or statement, autocomplete suggestions will have an emphasis on keywords that make sense at this syntactic position. In the below example the context-relevant keyword ‘true’ is suggested instead of generic completions that would not be syntactically sound.
if true t...
| Current | New |
|---|---|
 |
 |
Better awareness of instances as return types
Autocomplete will now show suggestions for functions that return an instance, as demonstrated by the below examples.
function getWorkspace()
return workspace
end
getWorkspace()...
function getMyScripts()
return game:getService("ReplicatedStorage")
end
getMyScripts()...
| Current | New |
|---|---|
 |
 |
 |
 |
Access to Luau type annotations
Autocomplete uses its knowledge of the Luau architecture to suggest completions for type-annotated variables. In the example below p is recognized as a ‘Part’ and completions for corresponding properties are provided.
local p:Part
p...
| Current | New |
|---|---|
 |
 |
General Improvements
Improved recognition of local variable names
The previous iteration of autocomplete often failed to provide completions for locally declared variables. This will never occur with Luau-powered Autocomplete.
local some_int = 5
so...
| Current | New |
|---|---|
 |
 |
Logic improvements to reduce noise and improve ordering in autocomplete suggestions
We’ve refined our autocomplete search algorithm to provide and rank completions in a more intuitive way across the board. Below, completions can be seen that are likely much more in line with the user’s expectations than before.
enu...
ran...
| Current | New |
|---|---|
 |
 |
 |
 |
Identifying Expression Type: The Gritty Details
(you’ve been warned)
The new Autocomplete system (as well as a few other Script Editor features) use Luau types to provide accuracy in their suggestions and checks. Better types lead to better performance. In strict mode, everything behaves as intended. However, in nonstrict and nocheck mode, there is not enough type information present to inform these features - many expressions just return type “any” in these modes.
So what do we do? In the background, Studio actually runs two typecheck passes - one in whatever mode is specified in the Script header and one that is always in strict mode. This second strict pass is then used to inform the features that require it. Where types are displayed in the Studio UI, we are following the principle of “display the type that is informing the feature”. This means that a single expression may display different types in different Studio UI. Luckily this isn’t too complex:
Type Hover and Script Analysis will always utilize the “less strict” type associated with the first type-check pass, corresponding directly to the mode indicated in the script header. It logically follows that in nocheck mode, Type Hover will not appear (as the language service is not keeping track of any types).
Type Hover
| --!nocheck | --!nonstrict | --!strict |
|---|---|---|
 |
 |
 |
Script Analysis
| --!nocheck | --!nonstrict | --!strict |
|---|---|---|
 |
 |
 |
Autocomplete, Signature Help, and Go To Declaration will always utilize the “most strict” type associated with the second type-check pass, regardless of the mode indicated in the script header.
Autocomplete
| --!nocheck | --!nonstrict | --!strict |
|---|---|---|
 |
 |
 |
Signature Help
| --!nocheck | --!nonstrict | --!strict |
|---|---|---|
 |
 |
 |
Go To Declaration
| --!nocheck | --!nonstrict | --!strict |
|---|---|---|
 |
 |
 |
This is a temporary implementation. As type-checking of nocheck and nonstrict mode scripts improves, we will be able to remove the redundant typecheck pass.
Coming Soon
There are a couple items that are currently missing from Autocomplete and will be added over the next several weeks prior to full release. These are:
- Embedded documentation to help inform completion selection
- Icon refresh for a cleaner look
- (fixed next week) A fix for the following bug where “else” does not show up when expected
if (1) then
print("Hello world!")
e...
- (fixed next week) A fix for this bug, where the correct capitalization of Workspace being marked as deprecated
Please try it out and tell us what you think!
Many, many thanks to @fun_enthusiast, @FunnyOldWorld, @swmaniac, @WheretIB, @1ceF1y, @mrow_pizza, @Apakovtac, @yohooyohoo, @HugoBLH, @cruiser_forever, @iriszh, @sunny0724 and @Rusi_002!
