CS2 Discussion: Features: Block assignment let and const operators

[GeoffreyBooth]

Building off of #1 and this comment, the great advantage of let/const is its block-scoping, i.e.:

let a = 1;
if (true) {
  let b = 2;
}
console.log(b); // undefined

This is a dramatic improvement over var, and a big reason why let and const have become popular features. This block scoping is probably something that CoffeeScript should have, separate from the feature of const that means “throw an error on reassignment.”

We could have both, via := and :== operators (or whatever two operators people think are best):

• a := 1 would mean, “declare a at the top of this block using let, and on this line assign a with the value of 1.”
• a :== 1 would mean, “declare and assign a on this line using const. If it gets reassigned later, throw an error.”

We don’t necessarily need the second operator, if we don’t care to give the “throw an error on reassignment” feature.

let has the same issue as var, in that its declaration is hoisted to its entire scope (what MDN refers to as the temporal dead zone), so let declarations should be grouped together at the top of their block scope similar to how var declarations are currently grouped at the top of their function scope. const must be declared and assigned on the same line, so it can’t get moved up.

So this CoffeeScript:

a = 1
b := 2
c :== 3

if (yes)
  b := 4
  c :== 5

would compile into this JavaScript:

var a;
let b;

a = 1;
b = 2;
const c = 3;

if (true) {
  let b;

  b = 4;
  const c = 5;
}

[kirly-af]

Hi Geoffrey, thanks for starting this discussion.
Personally, I rarely used felt the need for let in CS. As you mentioned, the first issue it solves is, variable hoisting out of declaration block:

if true
  foo = 42
console.log foo # 42, expected undefined

To solve the hoisting issue we could just transpile to let by default. The behavior would be more natural in my opinion.

The second issue it solves is shadowing:

foo = 42
unless bar?
  foo = 21
console.log foo # 21, expected 42

In this case, we need a way to shadow the inner block declarations. Maybe we could opt for something like the suggested := but I dislike both the operator and the fact it's not explicit enough.

I'd prefer something like the non-standard JS let expressions:

foo = 42
if true
  let (foo = 'a', bar = 'a') console.log foo, bar # a b
console.log foo #  42

There is also a non standard let block:

foo = 42
if true
  let (foo = 'foo', bar = 'bar')
     console.log foo
     console.log bar
console.log foo

As far as const is concerned, we probably could just use uppercase characters to declare constants like ruby does.

[GeoffreyBooth]

@kirly-af two quick notes: the let block was a standard that was proposed but then retracted, so I don’t think it’s something we should adopt; and ECMAScript const is very different from constants in other languages. const only prevents reassignment of a variable symbol; it doesn’t prevent the value of the variable from changing. Try in your Chrome DevTools console:

const obj = {};
obj.a = 42;
obj.a = 43;

This is a big reason why const is used all over the place in ESNext code.

[kirly-af]

Hi Geoffrey

I'm aware let blocks/expressions are non standard ES features. I'm not sure we should care about that, we are free to adopt any construct in CoffeeScript syntax. Anyway it was just a sintax suggestion, my point was to have explicit redeclaration (ie. let on its own would be fine as well) vs := operator.

Concerning const, I'm aware of it's behavior. However it's definitely not our concern here. Correct me if I'm wrong but this discussion only focuses on declaration syntax, const behavior could even be delayed to runtime (as you said throw on reassignment). Again my point was uppercase vs :==.

Let me know if some part of what I say is not clear, I don't mind elaborate more.

[GeoffreyBooth]

The uppercase issue has been discussed already, if not here than in #31 or #1. There were a lot of objections, because in most people’s ES2015 code most variables are consts. And an uppercase name implies that the variable is immutable, like a constant in other languages, when it isn’t in JavaScript.

CoffeeScript doesn’t have declarators such as var or function (though it does have class). I think it would be preferable to think of a new operator for let/const rather than introduce more anti-pattern declarators.

[kirly-af]

I agree let/const keywords should be avoided if possible.

My main concern is that ES2015 block variables will be completely unintuitive:

if true
  foo = 'a'
  bar := 'b'
console.log foo # 'a'
console.log bar # RefError thrown

For this reason, I think we should transpile all declarations to const (when possible) or to let instead of var everywhere. This way, the first console.log would throw as well. Of course, that would be a breaking change, but I think this is preferable.

Still, I really think, we should not allow shadowing in a language like CS. Python doesn't have block-level (understand if/while/for/switch) variables, like CS, and it's just fine. Even though I see how useful that feature is, I think it's probably just going to be error-prone.

[GeoffreyBooth]

I think redefining what = does is only possible if it isn’t a breaking change. Like if we can somehow know definitively that we can declare a variable with let or const instead of var and it won’t break anyone’s code, then sure, let’s use let or const. But if the behavior of = changes and such a change breaks existing code and forces refactoring, I think that that is unacceptable. This is such a core feature, anything that breaks = would require refactoring projects from top to bottom. No one would ever upgrade CoffeeScript.

[kirly-af]

I get your point, and you're completely right. Though I see more this change as a fix. Consider the example I used earlier:

if true
  foo = 42
console.log foo # 42

To me this is something that shouldn't be work. At least if we use let instead of var, foo will be undefined at the console.log level. Of course the best would be to make it invalid (ie. compiler error).
If this behavior is intended the refactoring would be limited to first initialize the variable before the if block.

[GeoffreyBooth]

Take it up with JavaScript. Until let and const, foo in your example could only be 42.

I don’t think code blocks like this are terribly uncommon:

if error?
  message = 'Error!'
else
  message = 'Success!'

alert message

Obviously there are more concise ways to write this in CoffeeScript, but imagine the messages were much longer and you can see why someone would write it out across multiple lines. I think code like this is common across many projects, and we can’t cause blocks like this to break.

[kirly-af]

Humm... yeah, I never did such thing but it's reasonable to think a significant number of users do this (I'm not making any judgement, just I never thought about doing such thing).

Still, I'd be in favor to keep it simple, as it is.

[lydell]

Just throwing a thing in here:

$ coffee -e 'console.log foo
foo = 5'
undefined

$ node -e 'console.log(foo)
var foo = 5'
undefined

$ node -e 'console.log(foo)
let foo = 5'
[eval]:1
console.log(foo)
            ^

ReferenceError: foo is not defined

$ node -e 'console.log(foo)
const foo = 5'
[eval]:1
console.log(foo)
            ^

ReferenceError: foo is not defined

[GeoffreyBooth]

Almost that exact example is discussed in the MDN article on let, under the heading Temporal dead zone and errors with let.

This goes back to my point about #31. I feel like we can either keep things as they are, or somehow allow let and const. It would make CoffeeScript too inconsistent to allow only const, which would behave so differently than var: not just the unreassignability that people expect to get from const, but also the block-scoping and the temporal dead zone (i.e. the lack of hoisting its declaration to the top of its scope).

[GeoffreyBooth]

I just did a little experiment where I changed the compiler to output let wherever it previously output var. It’s on this branch.

Amazingly, all but two tests still pass. The two that fail involve the REPL:

testRepl "variables in scope are preserved", (input, output) ->
  input.emitLine 'a = 1'
  input.emitLine 'do -> a = 2'
  input.emitLine 'a'
  eq '2', output.lastWrite()

testRepl "existential assignment of previously declared variable", (input, output) ->
  input.emitLine 'a = null'
  input.emitLine 'a ?= 42'
  eq '42', output.lastWrite()

So I guess the REPL would need to be updated to work with let. But everything else seems to work.

These two tests would pass as non-REPL CoffeeScript:

./bin/coffee -be 'a = 1
do -> a = 2
console.log a'
2

As does the other test. The above compiles to (in --bare mode):

let a;

a = 1;

(function() {
  return a = 2;
})();

console.log(a);

Even the example I posted above, where I thought var would be necessary:

if error?
  message = 'Error!'
else
  message = 'Success!'

alert message

becomes:

let message;

if (typeof error !== "undefined" && error !== null) {
  message = 'Error!';
} else {
  message = 'Success!';
}

alert(message);

Since we’re hoisting the let declaration lines all the way to the top of the function scope, the same scope that var had, I guess we can swap out var for let everywhere we’re currently using var? Is there an edge case where we couldn’t?

The bigger question is whether we should do this. I’m not sure let offers any advantages over var when used this way; presumably if let was used deliberately by a human, to define a variable within a block scope, the JS runtime might be a very tiny bit faster by not keeping unnecessary extra variables around within a larger function scope. But if we also automatically output const for variables we know never get reassigned, assuming such a determination could be made, then presumably we could get some additional runtime performance benefit from const. If nothing else, our output would look much more modern.