[CS2] Docs: Need to add breaking changes info about `=>` differences in CS2

[boris-petrov]

foo = bar =>
  console.log arguments

Is compile to:

foo = bar(() => {
  return console.log(arguments);
});

But according to this, arrow functions do not have their own arguments. I think this is a bug in CoffeeScript 2. Whenever arguments are used, that function should not compile to an arrow function. Or do you have some... um... arguments against that? :)

[vendethiel]

That's correct:

> (function f(x) { return (() => arguments)() })(1)[0]
1

[boris-petrov]

@vendethiel - I understand what happens. I'm saying that this is not consistent with what one would expect from CoffeeScript. There are only anonymous functions in CoffeeScript which means that I can never get the real arguments of a function which is passed as an argument. I think this will break tons and tons of code. As it did mine.

Again, I'm saying that CoffeeScript should compile lamba functions that use arguments inside the old way - by capturing this and then using function() .... Do I make more sense?

[connec]

We've adopted ES2015 semantics for fat arrow functions to reduce the barrier for users working in both languages.

The best way to achieve this now would be to use a splat:

(args...) => console.log args

[connec]

This probably needs to be documented as a breaking change if it's not already. Edit: looks like it's not.

[boris-petrov]

I don't think it is, I checked the documentation. I could have missed it though. But this is kind of bad... another example:

originalWindowError = window.onerror
window.onerror = (messageOrEvent, source, lineNumber, columnNumber, error) => # general window errors
  @_notify(error)
  originalWindowError?(arguments...)

How can I achieve the same effect with CoffeeScript 2?

[vendethiel]

Again, I'm saying that CoffeeScript should compile lamba functions that use arguments inside the old way - by capturing this and then using function() .... Do I make more sense?

Yes, thank you. I agree it's weird that -> and => have different arguments semantics.

[vendethiel]

If anything, it doesn't seem to be documented on /v2

[connec]

I agree it's weird that -> and => have different arguments semantics.

We could go down the route of normalising that, but there are quite a few cases to consider as arrow functions also behave differently with respect to this and super, and possibly other subtle things. For example:

class A extends B
  f: ->
    setImmediate(=> super arguments...)

This would need to account for the fact that arguments can't appear in arrow functions, and super can't appear in regular functions, and do some kind of shenanigans...

var A

A = class A extends B {
  f () {
    return setImmediate((...args) => {
      return super.f(...args)
    })
  }
}

As you note, it gets even more interesting with arguments. For functions with super and arguments we would probably have to have a spread argument, pull out the values separately, and replace all occurrences of arguments with the spread.

We could choose instead to take the breaking change (possibly with a compiler error for arguments in fat arrow functions?).

[connec]

Re: your example @boris-petrov, I guess a workaround for now would be destructuring:

window.onerror = (args...) =>
  [ messageOrEvent, source, lineNumber, columnNumber, error ] = args
  @_notify(error)
  originalWindowError?(args...)

[boris-petrov]

@connec - I agree, what you propose would fix my specific usecase, but if I were designing the language, I would strongly disagree with the idea that -> and => produce such different results. I didn't know that in ES6 arrow functions had such semantics about arguments and I think it doesn't make much sense and would confuse many people.

What I would do is I would preserve CoffeeScript 1 semantics - -> and => would differ only on the this binding and arguments would always have the "correct" value. I personally have a couple of examples where the new semantics don't make sense and I don't have a single case where the new one would be more useful.

I'm not the one to make decisions, but again - if it were up to me, I wouldn't take the reduce the barrier for users working in both languages way. People who write in both languages (we ALL do) would know the difference. What matters is what makes sense and what would make the language a better one. And I generally think ES6's approach doesn't do that.

P.S. Also, I think this will break a lot of code. Lots more than anything else that isn't backwards-compatible. I spent 10 minutes today fixing backwards-incompatible things (which were "compile"-time errors) and one or two hours going after the arrow stupidity of ES6.

[GeoffreyBooth]

When I was implementing the change to use the ES =>, one thing that came up with regard to arguments was that arguments can be inherited from the parent function:

var a = function (b, c) {
  var d = () => console.log(arguments);
  d();
}

a(1, 2);
// [1, 2]

So we can’t simply throw an error if we see a variable named arguments inside an arrow function. And we can’t redefine what variables named arguments mean or do, or else code like the above won’t behave as it should. We’re using the ES => now, and it means we use the ES => semantics.

What we should do is document this under http://coffeescript.org/v2/#breaking-changes, along with any other differences between the CS1 => and the CS2/ES =>.