An interesting wrinkle in language design has been the rise of sophisticated linting and style tools like `jscs`. If you wish to deprecate `var` for instance, it is straightforward to write a jscs module to enforce that. Further, several large communities (node, wikipedia, etc) have published jscs "presets" that effectively define the subset of the language they use.
So in a meaningful way we are getting the tools to voluntarily deprecate features in a community-driven way. Certain quirks may always exist in the spec (although perhaps more and more they will migrate to compatibility appendixes), but can be effectively ignored for communities opting in to jscs presets. I note that certain ES6 features have also been written specifically to allow opt-in to sane behavior. For example, a `SaneArray` subclass of Array is often discussed here. Use of SaneArray instead of stock Array could also be enforced by jscs-like tools. (Although this means giving up Array literal syntax? So there's still a bit of awkwardness. And API boundaries are tricky. Future work!) Anyway, I look forward to a continued process of community-driven feature deprecation, and hope that we will continue to look for ways in ES7 to allow further opt-in fixes to our warts. (I also look forward to continued development of interesting rule sets and analyses in jscs and similar tools to shave off warts.) --scott
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
