ECMAScript 2016: Array.prototype.includes and the Exponentiation Operator
ECMAScript 2016 will include as new features only Array.prototype.includes and the Exponentiation Operator. Async functions will have to wait until next year.
According to the proposal, the following snippets of code show how to use this new feature:
assert([1, 2, 3].includes(2) === true); assert([1, 2, 3].includes(4) === false); assert([1, 2, NaN].includes(NaN) === true); assert([1, 2, -0].includes(+0) === true); assert([1, 2, +0].includes(-0) === true); assert(["a", "b", "c"].includes("a") === true); assert(["a", "b", "c"].includes("a", 1) === false);
Although initially the proposed syntax was
Array.prototype.contains, the committee replaced
includes because the former was not “web-compatible”, breaking a good number of websites.
The syntax of this operator is
Operator: var1 ** var2
A basic example is:
let cubed = 2 ** 3; // 2*2*2
The 2016 release will be a much smaller one compared to ES 2015 (ES6) which followed ES 5 released back in 2009. This is because it was decided in 2015 to release, if possible, a new version each year rather than a large one at 5-6 years. A condition for a feature to make it into the final stage of the specification is to exist at least “2 compatible implementations that pass the tests”, and this is the main reason other features have not made it. Regarding the two features that made it, Brian Terlson (@bterlson), the ECMAScript specification editor, told InfoQ:
ChakraCore has implemented Array.prototype.includes (and we will likely be taking it out of experimental mode soon, see: https://github.com/Microsoft/ChakraCore/issues/23). We also have the exponentiation operator under our experimental flag in ChakraCore. SpiderMonkey and V8 also implement Array.prototype.includes, and SpiderMonkey has the exponentiation operator. So from the spec process perspective, these features are good to go. But also, these features are in some ways easier to get implementation feedback on as they are smaller in scope.
In some cases, the TC39 committee can decide they need more than two implementations of a feature to accept it in the final stage. Such is the case of Async functions which is a desired feature still in stage Candidate. Terlson explained:
Async functions are indeed not in ES2016. The TC39 process does not mandate an exact requirement for when a feature has enough implementation experience (the process is documented here: https://tc39.github.io/process-document/) so it's a judgment call made on a feature-by-feature basis. Async Functions do have more than two interoperable implementations (Chakra implements it, in addition to TypeScript and Babel) but for a feature like Async Functions the committee wants to be sure there are no browser implementation issues (eg. broken websites, perf problems, etc.) and ideally would like to see another interoperable browser implementation hit the web before incorporating the feature into ECMAScript.
Other features in stage Candidate are: SIMD.JS - SIMD APIs, Object.values/Object.entries, String padding, Trailing commas in function parameter lists and calls, and Object.getOwnPropertyDescriptors. “Many of the other stage 3 will likely get onto the ES2017 train, but it is not guaranteed,” added Terlson.