Simple idea: - Add new Annex to language. - Define operation EmitDeprecationWarning(code) - implementations MAY show deprecation warning in implementation dependent way (it can depend on runtime flag, dev tools, not minified code, etc.); otherwise operation EmitDeprecationWarning is noop - Define when implementations SHOULD emit deprecations warnings - like using with statement, non-standard Reg-Exp properties, compile method, assign to arguments, getYear etc. - Language features can be removed after 10 (15?) years
On Wed, Jul 26, 2017 at 11:55 AM, Andreas Rossberg <rossb...@google.com> wrote: > As for the reoccurring assumption that deprecation would help simplifying > JavaScript implementations: no, not to a relevant degree. 80+% of the > complexity in a JS VM comes from the plethora of (sometimes ridiculous) > edge cases in the core semantics of JavaScript, its object model, implicit > conversions, etc., and the desire to make all that fast in the common case > without breaking correctness of the million special cases. None of that can > be deprecated without creating a completely new language. > > And clearly, modes or versions only make things worse in that regard. > Strict mode already is a pig when it comes to implementation complexity (in > retrospect, it does not carry its weight IMHO). ES6 made it worse. Our > experiments with strong mode a while ago increased complexity even further, > so much that the urge to rip it out again overtook very quickly. I for one > am eternally healed of modes. > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
