CS3 Discussion: Assignment scope

[aleclarson]

I know assignment scope has been discussed at length for CS2 (#4951), but I don't see a discussion in the context of CS3. So here it is.

 

Block scope =

I'm strongly in favor of changing = from var to let and using nearest block scope instead of function scope, as was proposed by @jashkenas here: coffeescript6/discuss#58 (comment)

 

Shadowing avoidance

There was also talk of adding a := operator for explicit avoidance of shadowing.

Another option is the let keyword (which invites inclusion of const).

Just today, I thought of :foo = 1 as another option.

 

Concerns

@jashkenas said in coffeescript6/discuss#58 (comment):

There should only be one way to declare variables in CoffeeScript. Not having to think about two different mental models of variable scope at the same time is precisely and specifically the raison d'etre of CoffeeScript in the first place.

..which rules out the := operator, but maybe not let or :foo =?

If = is changed to block scope, the shadowing problem can be fixed without having two mental models of variable scope.

In the same comment, @jashkenas said:

If y'all think that block scoping is inherently superior to function scoping, (I too feel that way, but only lukewarmly), then the time to make the breaking change is now. CS2 is the only big breaking change we've had in 6 years — so do it now, or don't do it at all.

..but I assume this discussion is still "up in the air" for CS3.

Let me know if I missed any other ideas or concerns.

[GeoffreyBooth]

There was some side discussion of this in #4847 (comment), but this issue could perhaps serve as a better canonical place to track it.

Here’s how I remember the consensus so far:

• Nothing related to scope was changed for CS2, because preserving backward compatibility was a top priority.
• If scope is changed in a theoretical CS3, no syntax would change. The only difference would be that instead of a var foo, bar, baz; line at the top of a functional scope, the compiler would output a let foo, bar, baz; line at the top of the block scope.
• Changing how scope works is a potentially massive breaking change that would prevent many, if not most, apps from upgrading. This has the potential to cause a split akin to Python 2 and 3, where both versions need to be maintained. The benefits from switching to block scope are probably less than the cost of a possible schism and the confusion caused by countless CoffeeScript examples across the Internet that assume function-based scope.

[aminland]

What about preserving the existing behaviour, while also allowing you to explicitly define a variable at the block level without hoisting it to the top (i.e. enable the use of var/let/const keywords and have it output directly as written)?

[GeoffreyBooth]

@aminland See the quote from above:

There should only be one way to declare variables in CoffeeScript. Not having to think about two different mental models of variable scope at the same time is precisely and specifically the raison d’etre of CoffeeScript in the first place.

Any solution that preserves the existing behavior while also allowing some other way to declare a variable means you now have two ways to declare variables. The consensus from the earlier issues was that preserving the simplicity of there being only one way to declare variables is our top priority. So really the choice is only between “do nothing” and “change the current output to be block scope instead of function scope.”

[aminland]

If those are the only options then let's please not break backwards compatibility... Block scoping wouldn't actually enable you to do anything you can't currently accomplish with function scoping...

[aleclarson]

preserving the simplicity of there being only one way to declare variables is our top priority

Backwards compatibility is probably the top priority, since we don't want to fracture an already dwindling community. Also, block scoping shouldn't be written off as too complex. The Javascript community seems to be thriving with the addition of block scoping. There is clear demand for such a feature in Coffeescript. I would argue the greater risk is not matching Javascript on that flexibility.

With that said, I think the best direction is probably adding the let keyword. Familiarity is important in reducing the mental barrier of switching between Javascript and Coffeescript.

[sa-0001]

i think block scoping is most correct and i would definitely never thoughtlessly define a variable within a for loop (for example), instead defining its initial value outside the loop if that's the intent. but while i know i would be able to migrate my code if all variable declarations became let by default, i also know i am in the minority - for everyone else it just 'breaks things randomly' (from their perspective), or they simply cannot upgrade.

so, unless there is a convenient way to use optional flags for such feature ({"blockScoping":true}, --blockScoping) then i think allowing use of the let keyword may be the only real possibility.

[GeoffreyBooth]

For the record, if block scoping were to be added to CoffeeScript in addition to the function scoping we already have, it would be via a new operator like :=, not the let keyword. Adding any new keyword would be a breaking change, whereas := would not be. Please review the top post and the discussions it links to before commenting.

[sa-0001]

Adding any new keyword would be a breaking change, whereas := would not be

let is a reserved keyword since no later than v1.2 - see also your own comment: #58 "neither let/const nor := would break backward compatibility"

For the record, if block scoping were to be added to CoffeeScript in addition to the function scoping we already have, it would be via a new operator like :=, not the let keyword. [...] Please review the top post and the discussions it links to before commenting.

For the record, it is clear from reading said comments that this is your opinion on the matter, and far from a universally-accepted truth. While I did not actually mean let specifically but a new keyword/operator in general, and in fact I may prefer :=, let's err on the side of not telling new participants to take a hike.

[GeoffreyBooth]

You are correct, let is reserved. Regardless, in the prior threads there was a consensus that if we were going to support both types of scoping, it would be via :=. Later on, a consensus formed that having two types of scoping is too complicated for CoffeeScript and we would rather keep the current scoping rather than have both. Hence the consideration for a potential future 3.0.0 breaking change where the one and only supported scoping becomes block scoping rather than function scoping.

[aleclarson]

Furthermore, it seems a new consensus has been established in regard to "block scoping by default" being too drastic of a breaking change, which has a strong possibility of fracturing the community.

I think the argument between let or := can be logically put to rest for the following reason. The := operator works better in expressions where the value is being assigned and returned simultaneously.

# Assign `y` with block scoping, then add its value to `x`
x + y := 1

# Looks like a syntax error
x + let y = 1

But I'm warming up to the idea of a package-specific flag to enable block scoping by default. Of course, you could argue this is toxic for open-source projects, since it would not be obvious whether the flag is being used without checking the configuration. But that should be their choice, instead of the language gate-keeping a useful feature.

[sa-0001]

I wish CS could change to block-scoping without causing further abandonment. I wish someone could make a sophisticated tool to help migrate code for this change. Or, I wish there were an elegant way to opt-in to new features per file/module. Unfortunately, adding a keyword or operator is simply so much easier than all of the above that it remains tempting.

Of course, "leave it like it is" may be good enough for people like me who simply prefer CS, not because of one particular feature or another.

Some (admittedly distasteful) ideas:

• What do they call the compiler flags at the top of some python files (ex. specifying utf-8 encoding)?
• Could a use statement at the top of the file specify something other than 'strict' (ie. compiler options)?
• Specifying the CS version per file/module, however ugly it may be, allows never having to worry about breaking changes (but also having to context-switch).
• Some techniques are more useful if it's your code, some more useful if it's third-party.

[GeoffreyBooth]

I agree, it’s an annoying problem. It’s problematic to increase complexity when one of our prime selling points is simplicity.

We could mimic ES5’s 'use strict' and add in-file configuration, e.g.:

'use block scope'

if yes
  x = 'block scoped!'

This is probably better than an extra compiler flag, for the reasons mentioned above (not knowing whether a file is written to be block or function scoped without looking elsewhere in the project, etc.). But is it really better than :=? It certainly doesn’t seem simple, and I haven’t seen JavaScript follow this pattern since 'use strict'. It also feels like it opens a crack in the door for all sorts of other compiler flags, which further degrades our simplicity.

[zeekay]

I'm a pretty big fan of block scoping as a default and think it would be a lot more intuitive for new users. I'd happily update all of my projects to properly support it assuming block scope became a default. I think mirroring modern JS here would have a lot of advantages long-term and be worth the intermediate pain.

I suspect most of my projects would require little if any effort to support a switch to block scope. An automatic upgrade tool could presumably hoist all variables to the top of function scope, no?

[aleclarson]

I agree with @zeekay. Block scoping by default is the way forward, and the upgrade path looks smooth. The JS community is evidence that the majority prefer block scoping. Anyone who disagrees can keep using CoffeeScript 2.