Const Keyword for Local Declarations

[bradsharp]

This document introduces the const keyword for local variable bindings, explaining its syntax, semantics, and potential drawbacks.

Rendered

[jackdotink]

The motivation is very weak and the drawbacks of breaking backwards compatibility are... bad.

The motivation boils down into preventing accidental reassignment, and enabling unspecified implementation optimizations. Accidental reassignments by and large just don't happen. As for the unspecified optimizations, luau today knows if a variable is constant or not, and if it is, it applies optimizations. Checking if a binding is ever reassigned is trivial.

I assume the suggestion of breaking backwards compatibility comes with the idea of a tool to allow users to migrate code. This is bad because such a tool is infeasible for the largest user of the language, roblox. The migration tool cannot be run at user's own leisure because roblox forces the latest version of luau, and the tool cannot be run automatically effectively because many users do not use roblox as a source of truth for their code.

All in all, this feature opens too many difficult questions for the lack of utility it provides.

[bradsharp]

The motivation is very weak

export is the primary motivation for introducing const-ness to the language. When we return from a module with exports we freeze the result (see why here). This leads to an issue where the variables can be reassigned but the return value itself doesn't change. If we're going to introduce const-ness to the language for export then it seems reasonable to expose it for general use at the same time.

I've added more details about this to the RFC.

the drawbacks of breaking backwards compatibility are... bad.

Instead of reserving const as a reserved keyword it can be introduced as a contextual keyword that is only valid in positions that local is also valid. This makes the change compatible with existing code as const foo = 5 would fail to parse today.

I've covered this in the RFC also.

[SPY]

What kind of error? Static(Parsing Error) or dynamic?
Difference is more obvious inside a function definition.

const a = 42
function foo() -- 1
  a = 43
end
foo() -- 2

Should we see an error at parsing of 1 or at the call of 2?
JavaScript picks option 2, but honestly I'm not aware of advantage of it. So I would prefer option 1.

[bradsharp]

I think it can be implemented as a parsing error but we may want a runtime error as a backstop for cases like loadstring. I would expect the error to be on the line of the actual assignment, in this case a = 43.

[bradsharp]

As an aside JavaScript likely picks (2) because it's the line that leads to a being mutated and without it the value remains constant. For sanity, I think we should stick to erroring on a = 43 even if the code is unreachable.

[vegorov-rbx]

JS goes crazier here:

const a = 42;

function bar(overrides) {
  with (overrides) {
    let foo = function() {
      console.log(a);
      a = 43;
      console.log(a);
    }

    foo();
  }
}

bar({ a: 50 }); // prints 50, 43
bar({ b: 50 }); // prints 42 and throws TypeError: Assignment to constant variable.

[SPY]

As I mentioned above it is not an issue right now.
But it can be in conflict with developing proposals, like destructive assignment.
Theoretically you can have something like that in you code now:

const {a, b}

and it sould be treated as a call to const with a single param.
Assuming destructive assignment will look like

const {a, b} = x

It can be an issue

[bradsharp]

As const variables must always be initialized const {a, b} would be invalid (and therefore treated as a function call) while const {a, b} = x remains unambiguous as this is invalid syntax today. The one downside I see if that this could become a gotcha, so we might want to consider a linter warning for const {a, b}.

[jackdotink]

@bradsharp While const {a, b] = x is not ambiguous, it is still not reasonably parsable.

[jackdotink]

It almost makes one want for a "Do not add destructuring syntax" RFC

[SPY]

Probably worth mentioning vararg multi assignment explicitly.

it should be fine from runtime point of view to have something like

function f() return 1 end

const a, b = f()

Because f can return multiple values in last position(same with ...). In that case b should be initialized with nil. But typechecker probably should complain here.

[SPY]

I think RFC in a good shape and can be merged.

[MagmaBurnsV]

There's 9 thumbs down. Shouldn't we wait for more community input?

A major problem with this RFC is that it's primarily motivated on fixing a hole caused by the current semantics of the export-by-value RFC. This motivation is entirely speculative and different semantics for export-by-value can and should be chosen to solve this instead.

Secondary motivation for safeguarding reassignment is also rather unpopular. Anecdotal experience from myself and others says that accidental local reassignments rarely happen, and more often we want cross-module immutability, which is taken care of with table.freeze.

[jackdotink]

I'm more concerned on the future compatibility concerns with destructuring syntax, as in, this RFC doesn't leave a path open for destructuring syntax.

[andyfriesen]

Something this RFC doesn't mention is that export (and therefore const) are partly motivated by optimization opportunities that we'd like to pursue. It's very easy for us to do constant folding and function inlining when we have a language-level guarantee that a symbol can never be rebound.

A const variable is equivalent to a variable declared with local however const variables cannot be reassigned after they are initialized.

It would be good to clarify that attempting to rebind a const binding also results in a runtime exception.

Drawbacks
Potential false sense of immutability: developers may misread const as implying deep immutability. This is mitigated by clear documentation and examples, but the risk remains.

It must be said that JavaScript has been living with this restriction for years now and it's not a huge problem.

[SPY]

Merged as a dependency for #42

[MagmaBurnsV]

I must strongly object to merging this RFC.

First, I think it is dishonest to say this is needed as a "dependency" for the export-by-value RFC. This is not true and even contradicts the RFC's stated motivation:

Since export already requires this guarantee to behave correctly, exposing const as a general language feature avoids introducing special-case rules and provides a simple, consistent way to express immutability of bindings where it is desired.

Nothing about exporting needs this, and it shouldn't be framed like that.

Second, as I've already said before, this motivation is very weak as its only substantial rationale is to close a feature gap caused by the current export-by-value semantics. This can instead be solved by adopting different export semantics that don't cause feature gaps, such as my proposed alternative semantics.

Even if the team is convinced that current export semantics are the best for static optimizations (I disagree, my alternative can also obtain these optimizations without introducing const-ness), that still doesn't justify implementing const before export-by-value has even been accepted.

[alexmccord]

Rebinding const can all be done at parse time, there's no need for a runtime error to rebind const. loadstring can only affect globals, which const isn't, it occupies a register (modulo const-of-const elimination) which do not carry into loadstring. See local x = 5 assert(loadstring("x = 7; print(x)"))() print(x) which prints 7 then 5.