CS2 Discussion: Question: Is conflating null and undefined a feature of CoffeeScript?

[GeoffreyBooth]

In CoffeeScript 1.x, null and undefined are often interchangeable:

• if foo? returns false whether foo is null or whether foo is undefined.
• ((a = 1) -> a)(null) and ((a = 1) -> a)(undefined) both return 1.

In ES2015, at least regarding default function parameters, null and undefined are not interchangeable:

• (function (a = 1) { return a; })(null) returns null.
• (function (a = 1) { return a; })(undefined) returns 1.

This has sparked a discussion in the PR where I’m trying to implement arrow functions (and by extension, ES-style default parameters) for CoffeeScript 2. Basically, if we want to preserve the current behavior where the default value is applied when a parameter is null or undefined, we need to keep the current generated output:

f = function(a) {
  if (a == null) {
    a = 1;
  }
  return a;
}

So if we want output like this:

f = function(a = 1) {
  return a;
};

Then we have to break backward compatibility and go with ES’ implementation of default parameter values applying only when the parameter is undefined, not null or undefined. We can’t do both (the default value and the null if block) because the default value could be a function call, for example f = (a = b()) -> a.

CoffeeScript 2 was going to break backward compatibility anyway, but we want to break as little as possible. Is this null/undefined interchangeability something that people value in CoffeeScript 1.x, or would you not miss it if it went away? How important is it that the generated JavaScript for a feature like default function parameters be as ES-like as possible?

[lydell]

In VimFx (~5k lines of CoffeeScript), undefined is never used as a literal – only null. If CoffeeScript were to break backwards compatibility regarding parameter defaults, I'd have to go through every function with parameter defaults (and all places the call those functions) and double-check all values that can possibly be null (to see if I need to change to undefined somewhere, which I most likely need to do in most cases). Being a crazy refactoring maniac, that wouldn't bother me personally very much though (other than a few regression bugs).

But for ? I think it really makes sense to check both null and undefined, because, to me, the point of using ? in the following code is to avoid exceptions: element?.getAttribute?('foo').

It would be nice to hear @jashkenas’ wisdom on this as well.

Is parameter defaults behaving different in CoffeeScript compared to ES a relief or a point of confusion for new CoffeeScript users? What about already experienced users?

[triskweline]

While null and undefined are sometimes interchangeable, they often are not. E.g. == doesn't conflate these (and it should never do). It's OK to decide this on a per-case basis.

Conflate for existential foo? => I think that 's a very handy feature to have

Conflate for default arguments => I'd much rather have the cleaner Javascript output. Note that "The compiled output is readable" is also a CS feature, it says so right on the homepage!

In the PR discussion, I get @lydell saying that he doesn't care about the difference, got into the habbit of using null, and is now tripped up by ES semantics. I don't care either most of the time, but happen to default to undefined instead. That's a recommendation from Douglas Crockford in Javascript - The Better Parts.

[jashkenas]

It's tricky. Having two slightly different values for nothing is absolutely a mistake in JavaScript, and it's something we tried to smooth over a bit in CoffeeScript my making undefined and null as interchangeable as possible.

But getting the clean output for the 2.X branch is also a desirable outcome.

I'd say that it's tragic, but go for the clean output for 2.0, and we'll live with the inconsistency.

[GeoffreyBooth]

We should be keeping track of breaking changes somewhere. A wiki page on the main repo? A wiki page here? A markdown file in the project? Part of index.html in the project?

[lydell]

Let’s start with a wiki page on the main repo.

[GeoffreyBooth]

Wiki page here. I’ve updated jashkenas/coffeescript#4311 to reflect this decision (assuming we’re going with ES syntax, at least for now).

[connec]

Paraphrased from jashkenas/coffeescript#4311 (wall of text incoming):

Full disclosure: I'm in the same bucket as lydell in that I've tended to use null rather than undefined, particularly as the last expression in procedures for returning an empty value. When I'm writing CS I like to live in a world where undefined does not exist.

I would rather lose ES2015's defaults and keep existence checks consistent. I really don't like the idea of defaults behaving differently to ?, ?=, etc. (though ?() gives precedent for that...). To illustrate a problem with this, currently you can use argument defaults to make values in functions 'safe' for existence checks, i.e. a default is as good as an existence check.

action = (options = {}) ->
  # We can safely call options.whatever here, since we know it's not undefined or null
  options.whatever

Admittedly this is also an issue with ES2015, but it's one that CoffeeScript solves by treating null and undefined as non-existent values, for existence checks and defaults. My issue isn't so much about allowing null as an empty argument, but more about just not having to think about the difference.

If clean output is such a desirable outcome, why not just skip CS and use ES2015? I appreciate that's a bit melodramatic, and CS adds much more value than just null/undefined unification, but it's one of the many CS features that make it so pleasingly consistent in contrast to JS' (especially ES2015's) syntax limitations and quirks.

Finally, I do feel we're being a bit flippant about changing CS semantics when there's no compatibility reason to do so, particularly when there's so much value in a release of CoffeeScript that fixes what's broken (classes) without breaking lots of backwards compatibility.

[jashkenas]

Finally, I do feel we're being a bit flippant about changing CS semantics when there's no compatibility reason to do so, particularly when there's so much value in a release of CoffeeScript that fixes what's broken (classes) without breaking lots of backwards compatibility.

I agree — but I think that's basically the whole point of the current plan for "CoffeeScript 2". CoffeeScript 1 can continue to be the nice little well-tended garden that it has been ... but the point of CS2 is to embrace as much of modern JS as we can, even if that means losing some nice things that we've previously enjoyed.

[GeoffreyBooth]

@connec does have a point about classes: some people might want to limit their breaking changes to “just” classes, to get the interoperability with ES classes that they need, and could care less about any other changes CS2 brings to the table. For such people it will be annoying to have to choose between 1.x’s lack of class interoperability and 2’s breaking changes that are unrelated to fixing classes.

As much as I hate to say it, we could release the classes fix as an off-by-default flag on 1.x, so that people have a way to opt-in to that breaking change without any of the others. The only other interoperability concern that 2 was planning to address was tagged template literals, but those can be implemented in 1.x too without breaking changes (whereas regular ES template literals, by contrast, need to be 2-only).

This might even be a way to thread the needle with regard to how we want to deal with classes in 2: the maximum-compatibility version, basically what @connec is working on in jashkenas/coffeescript#4330, could be the opt-in ES-compatibility classes for 1.x; and a new implementation of classes that more closely tracks the ES spec could be what’s in 2. This sounds like a lot of work, and I’m not saying I recommend it, but it’s an option.

[jashkenas]

Just for the record: I think that sort of muddled approach is the exact wrong way to go. It's already complicated, and the clarity of —

CoffeeScript 1 is the CoffeeScript you know.
CoffeeScript 2 is CoffeeScript brought as close to modern JavaScript as possible.

— is critical.

If you add a flag for classes in 1, next you're going to be adding a flag for async, and then for some sort of advanced module feature, and then another flag for ES destructuring ... and so on.

[GeoffreyBooth]

I agree, but I wanted to throw it out there as an option. I suppose someone could always make a fork of CS1 plus jashkenas/coffeescript#4330, if they really really wanted only the new classes but nothing else.

I guess the bigger question when it comes to “brought as close to modern JavaScript as possible” is, how close? We could disallow splats in function parameters that aren’t the final parameter, the way ES2015 does; that would certainly have made my PR far easier to implement. But that seemed like a pointless restriction to impose on CoffeeScript, even if that’s what ES requires.

I think we basically agreed in the other thread that prettier output alone is rarely good enough to justify a breaking change; but conforming to ES spec for parameter default values has a benefit beyond streamlined output, in that CoffeeScript would then behave more like ES2015 for people familiar with ES. It’s like if we add support for ...args in addition to args..., to make it easier for people coming from ES or going back and forth; there is some value in consistency with JavaScript, even if it means CoffeeScript itself is less internally consistent.

For the record, I think it’s worth conforming to ES on this issue at least. But I understand the complaint. Read up the thread of jashkenas/coffeescript#4311 and you’ll see it took me some convincing as to which “old” features we were going to preserve, even if it meant outputting lots of extra JavaScript.