Skip to content
Switch branches/tags
Go to file
Cannot retrieve contributors at this time

TC39 Meeting on July 2016

The last TC39 Meeting was hosted by Microsoft in Redmond, WA, USA. They have an enormous and beautiful campus there and the weather helped TC39 to have some productive discussions.

The agenda was a bit long with some items that didn't find time in the previous meeting. The good news is that most of the items got solved.

I have to repeat the same statement from my last report:

As this report is not the meeting notes, I'll run through the highlights in an order differently than they happened, prioritizing what I believe to be the more interesting, polemic or in need of more discussion. Remember that's subjective, and there's no irrelevant items.

ES2016 has landed

ES2016 (ES7) has landed!

The greatest part of ES2016 is the fact it's now a living standards with yearly based releases including the staged process development.

With this short release, we've only got two major new features, summarized as the Array.prototype.includes and the Exponentiation Operator and other minor changes.

There are some articles talking about this, here are 2 I liked:

You can find the current specs draft here at

6 months left for ES2017 and Async Functions

We have 6 months left before the release candidate for ES2017! There are some features already to become part of this version, as the Object.values and Object.entries and the String padStart and padEnd methods. Some other interesting are on the way as well, as we've got more features reaching stage 4 in this meeting.

The most important highlight of this report is a long waited feature that will be finally part of the standards. Async Functions! Come and share this celebration with Brian Terlson on twitter, he championed the feature and passed through a long and tough review process to add the tests for it.

test262 updates

As you may not know, I've been working on test262 for more than an year now. This project contains comprehensive tests for the standards features, including ECMAScript (ecma262) and its Intl extension (ecma402).

As the project has got an amazing coverage for the ES2015 and ES2016 editions, there are still some Pull Requests waiting for volunteers to review.

You can use the test262-harness tool to run the tests in your favorite runtime, or even NodeJS from the command line.

In the meeting we discussed about providing some sort of mentorship to help people get used to test262 and this is really important, as the development process requires proposals on stage 3 to have tests landed there before any further advance. This includes normative changes from the ecma262's repo.

Updates on the Intl specs (ecma402)

The Intl specs has got stage 4 for DateTimeFormat#formatToParts specs and stage 3 for Intl.PluralRules. Those were championed by Zibi Braniecki in the meeting.

New features on Stage 4

Trailing Commas in Functions

This is a weird and not so loved feature that reached consensus for Stage 4. That means that now you may leave a trailing comma in a function argument list or a function parameters list.

Can you see this little detail in there?

function foo(param1, param2,) {
  /* ... */

foo('arg1', 'arg2',);

If you break those lists in multiple lines, they might save you some time editing your code to add more items.

function foo(
) {
  /* ... */


To be fair, I'm avoiding this in my code, but someone else can find it helpful, who knows.

Async Functions

I've already mentioned it above, but it's worth to register it here in its own place. You can find the proposal here.

Soon you'll be able to see it in the current specs draft.

Object.enumerable{Keys,Values,Entries}, my first rejection

I've got my first rejection! I could not find any light of hope to advance Object.enumerable{Keys,Values,Entries} to stage 1. I did a nice presentation with John-David Dalton, but the proposed features tried to become a nice built-in api to replace a for-in loop.

It would be very useful for methods in many libraries, e.g. the jQuery.extend and several lodash functions. That was the best appeal for to have this landing as a new built-in feature, but it was not enough.

It was considered we can do the same without a for-in loop, including it's spec abstraction, crawling the prototype chain. Plus, Brendan Eich reminded us the for-in is a bad legacy, "never invest in the trailing edge".

Math extensions

Rick Waldron, now representing Bocoup on TC39, introduced a new proposal for Math extensions.

It contains a few methods and constants for few Math specific operations like Math.radians and Math.degrees.

The proposal advanced to stage 1 and you can find the specs here.

Date.parse fallback semantics

Morgan Phillips, from Mozilla, is working on a proposal to revisit Date.parse for a more consistent and useful behavior. Which is now on stage 1 as well.

This is a feature I'm waiting for in the specs. The problem to make it advance is not its behavior or anything, but the name.

You that naming is hard, right? There is still some disagreement on which name or namespace we'll have this native global reference.

This will probably become global only, without the System namespace.

Curiously, a research from Jordan Harband tells that global should not our JS ecossystem. Can you prove this is wrong? Make your feedback worth on the proposal's repo before the next meeting in September 2016.

This remains on Stage 2, but we can have a strong guess it will advance to 3 in the next attempt.

String trimStart and trimEnd

You might have followed all the news on String padStart and padEnd methods. As a new follow up, we have trimStart and trimEnd on stage 2.

Class public fields

This proposal advanced to stage 2 as a signal that TC39 wants to move this forward, but it does not say it will remain as it is currently proposed.

Be careful if you're an early adopter. The syntax is still a bit unstable and might change until it gets to the next stage. The = initializer is being revisited. That means when we still have a proposal that might change to some other operator.

Share Memory and Atomics

This proposal from Lars Hansen is still on Stage 2 but it's one of the most complex being discussed in the last meetings. The discussions got it really close to reach stage 3, which might happen in the next meeting. That will set a green light to find tests and experimental implementations.

This is an important extension for TypedArrays and I'm excited to see this moving forward.

RegExp changes/g

There are several new changes coming for RegExp, some of them fixing the API and some just adding new features.

RegExp Unicode Property Escapes

This adds Unicode property escapes in the form of \p{...} and \P{...}. That means you can find PI or maybe the pile of poo through a RegExp.

const regexGreekSymbol = /\p{Script=Greek}/u;
// → true

Disregard lastIndex for non-global non-sticky regexps

This is a small change from a PR from Claude Pache which I championed in the meeting.

It solves problems with observable operations on the lastIndex property in non-sticky, non-global RegExps. As any operation with that property in these cases are unnecessary, we don't need to observe get and set operations on it as well.

The change fixed found web compatibility issues and also removed irrelevant observable operations.

The distinct NaN values

Do you know the NaN follows the IEEE 754-2008 standards? That means a runtime can use any value that is specified there. The IEEE 754 is not an open standards, but I can tell you, is not a single one.

Since ES2015, you can find distinct values representing NaN in JS. This happens because you can find bit precision representations of NaN through operations with TypedArrays.

To protect any JS execution from weird randomness of different NaN values, the specs are shielded with a statement that demands a runtime to keep that same distinct value when you fetch it from the buffer. Without it, a piece of code could act differently running each time in the same runtime, when this behavior is not intended.

You can observe these values in this project, and hope the runtimes find some light to fetch the same representation. From this meeting, we've got no change in the specs, but you can follow any updates from this issue.


This proposal from Jordan Harband has finally advanced from stage 0 to 2. That means the proposal was complete enough to meet all the criteria for its now current stage.

It follows a similar behavior of jQuery's Ajax jqXHR#always and you can check more about it here.

Cancelable Promises

This proposal from Domenic Denicola is evolving in its stage 1 and will probably come in the next meeting for stage 2. It had a nice progress since the last time it was presented and still need a few adjustments.

We've got some discussion on a proposed extension for the try-catch block which would have a try { ... } else (e) { ... } to represent cancelations as exceptions that are not errors. I am looking forward how this will evolve until the next meeting. I'm honestly not in agreement with this, but that will require me some research on that proposal, which you can see here.


Yehuda Katz is working on this proposal for 2 years, and now it finally reached stage 2. If you work with Ember projects or maybe other projects using a mix of Babel + Classes, you might have tried some hint of how it's gonna work.

Co-championed by Brian Terlson, it got a hard stage advance, as noted by Google, this prososal doesn't support annotating parameters and other things, and there is no clear migration path to supporting those from this proposal. So that's something we - perhaps - might expect some changes.


Sebastian Markbage presented a nice new proposal for this method which would be useful for shallow comparisons with memoize operations.

It didn't achieve consensus for stage 1, but the TC39 delegates are interested to see some further investigations for these operations.

You can find the proposal here.

Final notes

We've got a lot of information, right? There are some minor details you can find in the meeting notes.

The timeboxed format worked well and shall be improved in the next meetings. That might result in larger reports but it also means progress.

Every feedback is welcome! I'm looking forward to see what's next.