CS2 Discussion: Features: Block assignment operator

[coffeescriptbot]

From @GeoffreyBooth on 2016-12-05 07:21

Splitting off from coffeescript6/discuss#35, this proposal is for just one new operator: :=, the block assignment operator. So 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 genuinely new feature added in ES2015, and a great improvement over var, which explains why let and const have become popular features. This block scoping that let and const each offer is probably something that CoffeeScript should have, separate from the feature of const that means “throw an error on reassignment.”

The new operator would behave similarly to =:

• a = 1 means, “declare a at the top of this function scope using var, and assign a here with the value of 1.”
• a := 1 would mean, “declare a at the top of this block scope using let, and assign a here with the value of 1.”

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.

What about const? Well, there’s really no reason we need it. It protects against reassignment of variables, and that’s all it does. Per this comment, it probably has no performance benefit in runtimes; and since const reassignments can be caught by transpilers (whether CoffeeScript or Babel) such reassignments are in practice usually caught at compile time, not run time. If we decide we want to provide a way to output const, for full expressibility of ES2015 and for this protection against reassignment, that could be a separate feature added later.

So this CoffeeScript:

a = 1
b := 2

if (yes)
  b := 3

would compile into this JavaScript:

var a;
let b;

a = 1;
b = 2;

if (true) {
  let b;

  b = 3;
}

Note about bikeshedding: Please refrain from feedback that says how you prefer the let keyword to :=, or that you prefer some other sequence of characters to :=. Ultimately the keyword or operator chosen is a personal preference decision, and will be made by @jashkenas and whoever implements this. There was plenty of discussion about this on coffeescript6/discuss#35. Thanks.

[coffeescriptbot]

From @DomVinyard on 2016-12-05 13:42

Strongly dislike :=, it's way too ambiguous as a visual metaphor. If you were introducing entirely new semantics, why not stick with the word let (for the sake of a couple extra keystrokes), however my vote would be to not expose two types of assignment.

Everything is var, or (probably is preferable) everything is let. Not both.

[coffeescriptbot]

From @edemaine on 2016-12-05 13:47

@GeoffreyBooth You've probably thought about this, but why are you hoisting the lets to the top of the block instead of just leaving them at the assignment? Your example could alternatively be compiled to

var a;

a = 1;
let b = 2;

if (true) {
  let b = 3;
}

The difference is in treatment of the temporal deadzone. Your compilation removes the deadzone, so use of a variable never causes an exception, while this compilation causes e.g. f(b); b := 3 to throw a ReferenceError. I don't know for sure which is better, but the exception might be preferable. (Can't imagine why using b before assignment could be useful...)

This is a larger deviation from current = behavior, but also seems easier to implement (no hoisting). Eh, I guess we still might need to figure out which block the := is in to prevent multiple assignments to the same variable (which is illegal in ES6, so if we want to avoid outputting illegal ES6, need to detect in CS6).

[coffeescriptbot]

From @edemaine on 2016-12-05 13:52

@DomVinyard There are lots of reasons to support let in some form, discussed on coffeescript6/discuss#35 in particular. Namely, let enables the programmer, when desired, to control where your variables are accessible, preventing accidental leakage and re-assignment. See also It’s a Mad, Mad, Mad, Mad World: Scoping in CoffeeScript and JavaScript (for example).

[coffeescriptbot]

From @rattrayalex on 2016-12-05 16:30

Speaking as the person who originally proposed the := operator, I actually agree with @DomVinyard on this one.

I'll try to write up the reasons soon.

[coffeescriptbot]

From @GeoffreyBooth on 2016-12-05 17:03

@edemaine Yes, the declaration is hoisted away from the assignment to follow the pattern established by = and var. See http://coffeescript.org/#lexical-scope. I feel like both should behave the same way for consistency (though obviously the let declarations would be at the top of the block scope, not the top of the function scope).

[coffeescriptbot]

From @GeoffreyBooth on 2016-12-05 17:05

@DomVinyard and @rattrayalex, the discussion in coffeescript6/discuss#35 was overwhelmed by bikeshedding of people arguing whether let or := were better. If you want to continue that argument, can you please open a dedicated thread for it? I think it would be more productive to improving this proposal if we could just take it as a given that the implementation will be :=. Thanks.

[coffeescriptbot]

From @jashkenas on 2016-12-05 18:58

I agree with @rattrayalex and @DomVinyard — CoffeeScript should try to be as minimalistic and boiled down to the essence as we can make it.

JS now has three types of variable assignment (four, if you count named function declarations). CoffeeScript should have one.

That said, CS2 breaking compatibility might be an excellent opportunity for us to switch over from var to let, wholesale — if you guys think it's truly a better choice.

[coffeescriptbot]

From @vendethiel on 2016-12-05 18:59

👍 for let. but we need to change some hoisting code.

[coffeescriptbot]

From @connec on 2016-12-05 19:33

@vendethiel or make a break in those situations. I tried to outline something along those lines in this comment.

[coffeescriptbot]

From @edemaine on 2016-12-05 19:53

@jashkenas All hoisted variables can probably be switched from var to let; that's the experiment of GeoffreyBooth's let branch (which still needs a bit of debugging). The point of the := operator is to enable creating variables localized to a given scope, i.e., hoisted only to the containing block. I know this idea has been raised before (it could even be added to CS1, by renaming variables), and you're famous for rejecting it. I'd like to think the outcome will be different this time because of ES6's introduction of let, so JS now supports variable scopes that are not function-wide. I believe CS should embrace this JS feature, given its many uses and ways it can help a programmer be more safe. I see your point about it increasing the complexity of CS, but I also worry about being too simplifying to the point of losing useful features.

[coffeescriptbot]

From @YamiOdymel on 2016-12-05 20:05

I think we should have a shorthand for let since we don't use var but = in CoffeeScript.

But as a Golang Developer, := sounds more like var to me.

[coffeescriptbot]

From @edemaine on 2016-12-05 21:05

@YamiOdymel Reading a little about Golang, it seems Go's var is semantically equivalent to JavaScript's let (the scope is the containing block). So the semantics proposed for CS := exactly match Go's semantics for :=.

[coffeescriptbot]

From @GeoffreyBooth on 2016-12-05 21:26

@jashkenas I guess when you mean we should only use let, do you mean only use let and only block scope? My let branch simply outputs let wherever var is output now, which effectively means that these are function-scoped lets, which we can certainly do if your goal is just to banish the var keyword from our output. We could even do that and still add := for block-scoped let output.

I would be very hesitant to get rid of function-scoped variables (i.e. what we have now). For example, consider this code:

if error
  message = 'Damn!'
else
  message = 'Woohoo!'

alert message

which currently becomes:

var message;

if (error) {
  message = 'Damn!';
} else {
  message = 'Woohoo!';
}

alert(message); // 'Damn!' or 'Woohoo!'

If we have only block-scoping, it would be output as:

if (error) {
  let message;

  message = 'Damn!';
} else {
  let message;

  message = 'Woohoo!';
}

alert(message); // Undefined

This can be refactored to still work with only block scoping, by adding message = undefined or similar on the first line, but I think this illustrates how drastic of a breaking change banishing function scope would be. I think we need both scopes, if we’re adding block scoping at all, hence the two operators.