Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CS2 Discussion: Features: Experimental flag? #4933

Closed
coffeescriptbot opened this issue Feb 19, 2018 · 6 comments
Closed

CS2 Discussion: Features: Experimental flag? #4933

coffeescriptbot opened this issue Feb 19, 2018 · 6 comments
Labels

Comments

@coffeescriptbot
Copy link
Collaborator

From @GeoffreyBooth on 2016-09-16 19:47

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.

@coffeescriptbot
Copy link
Collaborator Author

From @jashkenas on 2016-09-20 15:20

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".

@coffeescriptbot
Copy link
Collaborator Author

coffeescriptbot commented Feb 19, 2018

From @GeoffreyBooth on 2016-09-20 17:18

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 coffeescript6/discuss#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.

@coffeescriptbot
Copy link
Collaborator Author

From @mrmowgli on 2016-09-23 05:23

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.

@coffeescriptbot
Copy link
Collaborator Author

From @GeoffreyBooth on 2016-09-23 05:45

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 #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.

@coffeescriptbot
Copy link
Collaborator Author

From @mrmowgli on 2016-09-23 05:54

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

@coffeescriptbot
Copy link
Collaborator Author

From @GeoffreyBooth on 2016-09-23 05:57

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant