
ECMAScript 2018 Language Specification - treyhuffine
https://tc39.github.io/ecma262/?ref=HN
======
johnsonjo
I'm really hoping async iterators [1] will make it to stage 4, but from the
github I can't really tell what's holding it back as it has several browsers
with implementation (I know that's not the only requirement for stage 4, but
it's one of them.) I also noticed it's not on the agenda for the November
meeting [2]. I understand there are a lot of features being worked on
concurrently so it may not be finished by ES2018, but is there any chance
someone could give me an update on what's happening with it. I just think this
feature is amazing! And also thanks TC39 for all the great features coming to
ECMAScript!

[1]: [https://github.com/tc39/proposal-async-
iteration](https://github.com/tc39/proposal-async-iteration) [2]:
[https://github.com/tc39/agendas/blob/master/2017/11.md](https://github.com/tc39/agendas/blob/master/2017/11.md)

~~~
always_good
Async iterators will be cool.

Since Java blocks, you can implement a crawler as a custom iterator that makes
API requests / paginates behind the scenes and thus abstracts away the fact
that it's making a series of requests since the callsite just iterates over
the values as it finds them.

Would be nice to have that sort of abstraction in Node.

~~~
hdhzy
> you can implement a crawler as a custom iterator that makes API requests /
> paginates behind the scenes and thus abstracts away the fact that it's
> making a series of requests since the callsite just iterates over the values
> as it finds them.

Yep, that's what I had built when they were announced. I had an API that
returned a page and "next" pointer but the iterator just returned next item
(promise) and followed next links, for the API consumer it looked like a
regular collection. Pretty nice!

> Would be nice to have that sort of abstraction in Node.

Unfortunately Node APIs will probably always lag behind because it's hard to
rewrite everything using Promises...

------
heydenberk
It's not easy to tell from this document what has changed, but Dr. Axel
Rauschmayer does a good job here
[http://2ality.com/2017/02/ecmascript-2018.html](http://2ality.com/2017/02/ecmascript-2018.html)

~~~
paws
A few paragraphs down, you should find:

This specification introduces Async Functions, Shared Memory, and Atomics
along with smaller language and library enhancements, bug fixes, and editorial
updates. Async functions improve the asynchronous programming experience by
providing syntax for promise-returning functions. Shared Memory and Atomics
introduce a new memory model that allows multi-agent programs to communicate
using atomic operations that ensure a well-defined execution order even on
parallel CPUs. This specification also includes new static methods on Object:
Object.values, Object.entries, and Object.getOwnPropertyDescriptors.

~~~
growtofill
Nope, that’s a copy-paste from last year’s spec: [http://www.ecma-
international.org/publications/files/ECMA-ST...](http://www.ecma-
international.org/publications/files/ECMA-ST/Ecma-262.pdf#page53)

~~~
bterlson
I will be writing the ES2018 intro prose around when we send ES2018 draft to
ECMA for ratification (few months away yet).

------
nikcub
Optional catch binding[0], which is at stage 3, seems like a bad idea[1] and
has been pointed out as such[2]

[0] [http://2ality.com/2017/08/optional-catch-
binding.html](http://2ality.com/2017/08/optional-catch-binding.html)

[1]
[http://wiki.c2.com/?EmptyCatchClause](http://wiki.c2.com/?EmptyCatchClause)

[2] [https://github.com/tc39/proposal-optional-catch-
binding/issu...](https://github.com/tc39/proposal-optional-catch-
binding/issues/2)

~~~
acdha
The github issue seems to cover this well: existing linters have code to cover
intentionally unused bindings and this is a cleaner way to express that. Do
you disagree with the rationale in that discussion?

~~~
nikcub
I'd be more ok with it being paired with exception filtering (or what Netscape
called conditional catch clauses), ie.

    
    
        } catch (e if e instanceof CriticalError) {
            // handle critical
        } catch (e if e instanceof TypeError) {
            // handle type mismatch
        } catch () {
          
        }
    
    

so you could at least handle critical and other errors before blindly
silencing - but for some reason exception filtering/conditional catch hasn't
come up in ECMA

------
pc2g4d
This page is confusing because it describes itself as ECMAScript 2018 but the
features it lists are those I've associated with ECMAScript 2017.

Looking at the Github repo, you can see that they changed it from 2017 to 2018
on March 31st:
[https://github.com/tc39/ecma262/commit/8340bf9a8427ea81bb0d1...](https://github.com/tc39/ecma262/commit/8340bf9a8427ea81bb0d1459471afbcc91d18add#diff-3540caefa502006d8a33cb1385720803)

So what happened to 2017?

~~~
bterlson
Official standards are moved to ECMA's website. E.g. ES2017 is here:
[https://www.ecma-
international.org/publications/files/ECMA-S...](https://www.ecma-
international.org/publications/files/ECMA-ST/Ecma-262.pdf). The GitHub site is
mostly targeted toward implementers who are always working off the latest
draft for new spec or implementation work.

------
xamuel
Template Literal Revision [1] is a welcome change, but still falls way short,
as there's still no way to easily include the backtick itself inside raw text.

I wish ES would adopt python-style triple-quotes, so you could do things like:

String.raw```Look, this is a backtick: "`"```

(The inability to do this is a pain point when you want to embed a language in
ES and that language itself makes use of backticks.)

[1] [http://2ality.com/2016/09/template-literal-
revision.html](http://2ality.com/2016/09/template-literal-revision.html)

~~~
mistercow
Can't you just do `Look, this is a backtick: ${'`'}`? Or are you not counting
that as "easy" because it's horrible.

~~~
xamuel
Suppose I wanted to embed your solution itself into a template literal. It
would look like this:

`${'`'}Look, this is a backtick: \${'${'`'}'}${'`'}`

~~~
Arnavion
Rust has a nice solution to this.

    
    
        r"foo" == "foo" // r" means the literal ends at "
        r#""foo""# == "\"foo\"" // r#" means the literal ends at "#
        r##"r#""foo""#"## == "r#\"\"foo\"\"#" // r##" means the literal ends at "##
    

and so on.

Basically you add as many # outside as necessary to distinguish the end of the
literal (double-quote followed by some #) from any such sequence in the middle
of the literal.

~~~
analogic
just blue my mind. is there a babel plugin that will let me do this?

------
bascule
I guess BigInt (i.e. native integer support) is only stage 3:

[https://github.com/tc39/proposal-bigint](https://github.com/tc39/proposal-
bigint)

It's the feature I'd most like to see added.

~~~
ralusek
Didn't even know that was on the docket, that's awesome. Would doing
operations on them automatically cast them to float64? I know they offer
integer typed arrays, but any mathematical operations will automatically cast
them to float64, which is a bummer.

~~~
nikcub
coercion throws a type error - you can only do ops between bigints

------
allenwb
That document is an incomplete working DRAFT for the next edition of the
ECMAScript standard.

Don't assume that the current snapshot is feature complete.

~~~
bterlson
More strongly, the draft is incomplete by its very nature. If you care about
having only complete and ratified standards, do not use the GitHub snapshot.
Use the official versions hosted on ECMA's website ([https://www.ecma-
international.org/memento/TC39-M.htm](https://www.ecma-
international.org/memento/TC39-M.htm)).

------
mstade
I wish the spec included a more bullet pointy changelog from the previous
version, but at least it has this paragraph:

    
    
      This specification introduces Async Functions, Shared Memory,
      and Atomics along with smaller language and library
      enhancements, bug fixes, and editorial updates. Async
      functions improve the asynchronous programming experience by
      providing syntax for promise-returning functions. Shared
      Memory and Atomics introduce a new memory model that allows
      multi-agent programs to communicate using atomic operations
      that ensure a well-defined execution order even on parallel
      CPUs. This specification also includes new static methods on
      Object: Object.values, Object.entries, and
      Object.getOwnPropertyDescriptors.

~~~
growtofill
That’s ECMAScript 2017.

~~~
mstade
You're right, thanks for the correction. Very confusing language though, an
oversight in editing perhaps?

------
sandstrom
I hoped decorators[1] would make it, but seems unlikely (looks like they're
still at stage 2).

[1] [https://github.com/tc39/proposal-unified-class-
features](https://github.com/tc39/proposal-unified-class-features)

~~~
javajosh
Having spent a long time with Java I believe I understand the limits of this
style of coding; in my considered opinion, composition is almost always better
than inheritance. This is true regardless of the type of inheritance, be it
prototypal or class-based (in appearance or reality). Therefore, adding
features to JS to make class-like inheritance _slightly better_ is not a
trade-off I would make, favoring a simpler language over a feature who's use
shouldn't be encouraged.

~~~
always_good
They're talking about this section in particular:
[https://github.com/tc39/proposal-unified-class-
features#deco...](https://github.com/tc39/proposal-unified-class-
features#decorators)

Where decorators are sugar for higher order functions, even capable of `Class
-> Class` transformation, which makes them much different from Java
annotations.

------
sterlingfs
Im honestly not trying to be like TLDR, but a revision log would be immensely
appreciated.

~~~
bterlson
I hear ya. Once the spec is finalized for the year I produce a change log. I
have done so in between versions before but things tend to be menial and/or
change a lot and it was a lot of work for not too much gain. Willing to go
back on this. You can always watch the commits go in here though:
[https://github.com/tc39/ecma262/commits/master](https://github.com/tc39/ecma262/commits/master).

------
growtofill
According to [the
repo]([https://github.com/tc39/proposals/blob/master/finished-
propo...](https://github.com/tc39/proposals/blob/master/finished-
proposals.md)) only one minor feature had reached stage 4 since last year. Not
sure why this is on top HN.

~~~
irrational
My understanding is ES2015 was huge, but E2016, ES2017, ES2018, etc. are
comparatively tiny.

------
acjohnson55
My number 1 wish for JavaScript is that it could become fully expression
oriented. There's been talk about `do` blocks, which would modify control
structures like `if` to become expressions but I don't think that's gone
anywhere.

------
gitconnected
Still a working draft, but great to see all the potential updates

------
ryanmarsh
From section “4. Overview”

 _ECMAScript is an object-oriented programming language for ..._

heavy sigh

~~~
always_good
As opposed to what?

Prototype-based is a form of OOP: [https://en.wikipedia.org/wiki/Prototype-
based_programming](https://en.wikipedia.org/wiki/Prototype-based_programming)

And "functional programming language" would be way too fine a point, like
calling Ruby an FP language.

~~~
pitaj
Multi-paradigm

