Description
From @GeoffreyBooth on 2016-09-24 20:22
How do we feel about potentially adding new sugar features at this point? By “sugar” I mean a feature like ? that has no corollary in JavaScript, that CoffeeScript provides as a shorthand to make it easier to type a complicated JavaScript construction (like => and class were when they were created). If there’s a better/more proper name for such features than “sugar,” please enlighten me.
We have two recent proposals, #4144 and coffeescript6/discuss#39, concerning new operators that are sugars. Regardless of their specific merits, how do we feel about such proposals in general? I almost feel like we should take a position of “no more sugars,” period, as a way to avoid future cases like class or ... where ECMAScript adopts our feature but then implements it in a different way. The pipe operator, in particular, is already a debated proposal in ECMAScript; I feel like adopting it in CoffeeScript before it exists in ECMAScript (if it ever appears in ECMAScript) could just set us up for trouble down the road when their implementation differs from ours.
Sugars made sense when JavaScript was static and unchanging. But now that it’s a moving target, I wonder if CoffeeScript should still be trying to innovate new language features. It sucks, I know, to make us dependent on ECMAScript for innovation and close off our community’s creativity; especially since we’re the ones who came up with many of ES2015’s best features, like =>. But do we want to continue to play that role, if it means potentially more breaking changes in the future?