ECMAScript 2018 Language Specification | Hacker News Reader

ECMAScript 2018 Language Specification

tc39.github.io

149 pointstreyhuffine48 comments

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 [2]: https://github.com/tc39/agendas/blob/master/2017/11.md

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.

> 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...

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

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.

Nope, that’s a copy-paste from last year’s spec: http://www.ecma-international.org/publications/files/ECMA-ST...

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

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

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

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

If anyone has any data on this topic I would love to hear and understand it!

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?

That's true, but in that case adding optional catch binding is completely useless.

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

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...

So what happened to 2017?

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

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

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

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

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

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.

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

Web components are the answer for creating composable templates.

Won't this cause issues if i ever want to embed "```"?

Pretty much. This is why some languages offer the ability to define an arbitrary quote end token.

Encoding backtick as unicode escape is one easy enough and "clean" way:

`foo \u0060bar\u0060`

you can escape backticks with \

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

https://github.com/tc39/proposal-bigint

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

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.

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

It was only recently bumped up.

You can help out by contributing testing etc. in babel[0] or typescript

[0] https://github.com/babel/babel/pull/6015

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.

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).

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.

That’s ECMAScript 2017.

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

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

Probably not ES2018, but 2019 is looking likelier now thanks in part to excellent work by Daniel Ehrenberg (@littledan).

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.

They're talking about this section in particular: https://github.com/tc39/proposal-unified-class-features#deco...

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

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

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.

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

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

A small update is just as important news as a large update. It's a signal about where Javascript stands as a language.

There are many proposals sitting at the cusp of the stage 3 to stage 4 transition. There will be a couple more meaty things to make it. I suspect we'll end up with more proposals ready than I have time to integrate into the main spec :)

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.

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

From section “4. Overview”

ECMAScript is an object-oriented programming language for ...

heavy sigh

As opposed to what?

Prototype-based is a form of OOP: 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.

Multi-paradigm

Reply on news.ycombinator.com