CS2 Discussion: Features: Experimental flag?

[GeoffreyBooth]

Per this comment and this one, @jashkenas is opposed to adding new features to CoffeeScript until they’re not just an approved spec, but implemented in a few runtimes. His logic is that however “final” specs seem to be, the proof is really in the implementation; and we shouldn’t get ahead of ourselves supporting something that may change when browser or Node support for that feature finally ships. This makes supporting a feature like await problematic. Its spec isn’t finalized, and it’s currently implemented only in Edge and in Chrome behind a flag.

Yet it’s one of the most popular requested features. An entire fork of CoffeeScript was created, Iced CoffeeScript, to implement this one feature.

Leaving aside the specifics of await, I wonder if there’s a way to satisfy both camps for features like this one. What if we created a flag called --experimental, and put features like await in there? The docs would define experimental features as subject to breaking changes or removal at any time, like in Chrome. If and when await graduates to evergreen browser support, we can move it out of the --experimental zone into the language proper; or if it never gets approved or widely implemented, we drop it. But this way we at least have the option of giving people these high-demand features, without committing to them.

[jashkenas]

This is kind of similar to the 2.0-alpha vs stable issue. Flags can make the compiler internals uglier than necessary — but I have absolutely no objection to an experimental branch that is periodically merged into master when the underlying features mature. It can even be released on npm as "experimental".

[GeoffreyBooth]

The only issue I see with a branch is then do we have 1.x-experimental and 2.x-experimental? So that people like in #40 who want to stay on 1.x but get await have a way to do so?

Or maybe we should just accept await as being “implemented enough” (currently full support in Edge, behind a flag in Chrome, per kangax) to support as ESNext output, and we can kick this can down the road until the next high-demand feature comes along? await is the only one at the moment, and it might be until after 2.0.0 final launches.

[mrmowgli]

Where is Node in terms of implementation? Babel? I imagine only very closed environments would want async natively in the browser if you still have to enable flags for it.

However I can see this being used the moment it is released in Node code bases. If current versions of node are supporting it, or babel then I would want this in the 1.x experimental code base.

I have iced coffee in use in a few places because it really is a useful feature, and one that is much simpler to get than promises.

I suspect if the docs are clear about what edge cases aren't covered or work arounds for them, it would be fine to enable them as experimental.

[GeoffreyBooth]

Node doesn’t support await yet. However if it’s behind a flag in V8 in Chrome, then presumably it’s not far off in Node.

We’ve been discussing this in jashkenas/coffeescript#3757. I think the consensus is that it shouldn’t go in 1.x because await isn’t currently a reserved word, and therefore declaring it a keyword is a breaking change (and I don’t think it’s all that unlikely that some people out there have created functions named await). At the moment I don’t think there’s enough energy to maintain not just master (1.x) and the 2 branch, but also one or two experimental branches.

[mrmowgli]

So push this into the 2.0 branch under the experimental flag?

[GeoffreyBooth]

Just the 2 branch. At the moment I don’t think we’re doing an experimental flag or experimental branches. The only feature that might’ve gone behind such a flag or in such a branch would’ve been await, but we’re judging it mainstream enough to be part of the regular 2 branch.

[coffeescriptbot]

Migrated to jashkenas/coffeescript#4933