- 1 New and improved builtin APIs
- 2 New syntax (stuff that affects the front end and/or bytecode)
- 3 Updating SpiderMonkey extensions to the ES6 spec
- 4 Harmony infrastructure
- 5 Modules
- 6 New APIs that are in modules
- 7 Incompatible changes
- 8 Proposals that should not create any work for us
New and improved builtin APIs
Most of this stuff does not need to touch a lot of code. None of it requires a Harmony opt-in. This is great stuff for new contributors to start work on.
- Simple Maps and Sets - The spec is incomplete but I will be landing what's there now in bug 697479.
- Binary data - bug 578700
- New reflection methods Object.getPropertyDescriptor, Object.getPropertyNames
- Number.isFinite, isNaN, isInteger, and toInteger
- String.prototype.repeat, startsWith, endsWith, contains, toArray
- New reflection API that complements proxies: harmony:reflect_api
- More math functions - Proposed are: Math.log10, log2, log1p, expm1, cosh, sinh, tanh, acosh, asinh, atanh, hypot, trunc, sign; perhaps gamma and erf; and perhaps randomInt(n). See bug 717379.
- ES6 will spec that Math.random does not share state across multiple globals.
New syntax (stuff that affects the front end and/or bytecode)
This stuff isn't terribly hard either, for the most part.
- for-of loops - bug 699565 - This is I'd say better than half done. It was easy. XPConnect must be updated so that arraylike XPCOM objects cooperate with for-of.
- Parameter default values
- Rest parameters - bug 574132
- Spread operator - bug 574130 - The operator can appear in two places: function calls and array literals. Maybe two bugs would make sense.
- Proper tail calls
- Extensions to object literal syntax
- Quasi-literals Bug 688857
Updating SpiderMonkey extensions to the ES6 spec
We've implemented a ton of stuff, dating back years, that is going to be in ES6 but in a slightly different form.
There is a ton of verbiage here and it is still under active development. Still, I think it should be pretty easy to implement. We already have the forwarding code. We can keep
createFunction without a lot of extra effort.
Generators and comprehensions
- Certain scoping details in array comprehensions and generator expressions are probably different from what we have implemented.
function*syntax - bug 666399
- Allow returning a value from a generator - bug 666404
- There are probably one or two other minor details - details of StopIteration, that kind of thing.
let, const, and block functions
- Top-level let shouldn't be the same thing as var, per dherman: bug 589199
- TC39 is specifying that reading a let-variable before it is initialized is an error, which will be a separate bug.
const- bug 611388
- Block functions - bug 585536 (note - opt-in only, still banned in ES5 strict mode)
- Per loop iteration binding of let/const.
Some minimal steps here are a prerequisite to doing the features that require a Harmony opt-in: modules and import, block-scoped functions,
typeof null, and lexical scoping of names declared at toplevel.
- New SM version number - This is enough to get started on harmony features with only shell tests.
- Opt-in via type="text/ecmascript;version=6" or whatever - bug 694107
- Per-script opt-in syntax ('use harmony;' or whatever)
- Opt-in via HTTP header?
- Whole-page opt-in via HTML feature?
Modules are bug 568953.
modulesyntax, scoping semantics, module objects
- Hook up
from "url"and async module loading to Gecko
- Module loaders
With a Harmony opt-in, programs get very different global binding behavior. The bindings are no longer shared with the global object's properties. This is a major change.
New APIs that are in modules
- Reorganize the standard library into modules
- Private name objects - bug 645416
- A few functions for iterating over object properties
Harmony may change some ES1-5 behavior, if it empirically turns out to be doable without breaking the Web.
- Change how eval decides which value to return
- typeof null == "null" with Harmony opt-in - bug 651251