Warn, with detail, against certain --harmony flags?

[domenic]

One of the most consistent topics I see in IRC is people trying to use --harmony-arrow-functions. I continually need to warn people away from them. I've also seen people try to use --harmony-proxies and --harmony-modules. All of these features are dramatically non-spec-compliant. (Whereas, other non-shipping features like --harmony_arrays or --harmony_unicode are fine, not to mention the staged features.)

I wonder if we should include a warning on the ES6 page specifically against these three features, explaining what's broken with each of them, so that people know what they're getting in to?

I feel like there's still some cleanup to do in peoples' mindset here. For so long v0.11 shipped with almost-spec-compliant generators, and people thought slapping on --harmony_generators was no big deal, which was mostly true. But that seems to have trained people to think --harmony_arrow_functions or similar are also no big deal, which is wrong.

[dotproto]

+1 for more explicit documentation. IMO that's exactly the kind of information I'd want to find in the docs if I was exploring io.js as a way to explore ES6 feature.

[ruimarinho]

The lenient and widespread usage of harmony flags on 0.11 definitely passed a message of approval, which is perfectly understandable due to the ultra slow adoption of newer V8 versions. However, I'm ambivalent on this, so I'll try bring to the discussion some considerations of this approach:

• Listing particular features that are labeled as in progress in V8 (like --harmony_arrays or --harmony_unicode) but that are actually fine to use might pass the wrong message to developers, causing a tendency to infer that using harmony flags has been officially sanctioned by io.js. In fact, if we agree on adding this detailed information, we could focus on re-enforcing the message instead that using harmony flags is not recommended by listing examples of why it would be bad (e.g. --harmony_arrow_functions on io.js <= 1.3.0 could cause this or that). I think people in general use the flags because apparently they work fine (i.e. (() => "foobar")() works).
• It brings a considerably maintenance effort which probably requires someone knowledgable of V8 internals - specifically you - to keep that list up-to-date. Generally, how do we know a feature marked as "in progress" in V8 is spec-compliant and ready to use?
• I doubt developers want to deal with all the little quirks (again) that command line flags introduce for daily usage, but for the curious ones, listing those ready features ahead of time can actually feed their experimentation side, just like co, koa and company brought generators to a wider audience. Like many developers out there, I personally enjoy being up-to-date with the progress of those features. For example, I recently asked @caitp about what was missing from the rest parameters implementation to move to the staged area. In my opinion, that insight would be very interesting to share.

So, in general, if we can convey the right message regarding generic use of harmony flags and somehow list "ready" feature ahead of time in a way that does not distort that message (listing this content in a less prominent section?), I'm all for it.

[domenic]

The goal should be to discourage use of --harmony features in general---none of them are safe to use. Some of them are more unsafe than others though, and if those ones are also popular, I think it'd be good to specifically warn people against them.

[bnb]

This is an issue that can be handled by the Docs WG. I've marked it as invalid and docs to ensure its responsibility is handed to the Docs WG. If you want to discuss this issue, see nodejs/docs#10.

[caitp]

Just fyi, rest parameters shipped this morning, not too different from how they were before. We still want to improve the perf to at least match _.restParams, though. So I guess you can probably consider those acceptably safe. (Unless of course we need to revert then for one reason or another)