ecma262 VS proposal-cancellation

These aren't valid JavaScript (@@iterator would throw an error). They are actually internal Symbols used in JavaScript. They are used to implement features like iteration, instanceOf, and such internally. They actually might get removed or changed

Note that in previous editions, the ECMAScript® Language Specification used the term "lexical environment" before it decided to rename it to "Environment Record" so you might encounter this term in other definitions and tutorials.

For a new specification to be written, you need two things, a_ technical committee_, and a standard. The standard specification for JavaScript is called ECMA-262, and the technical committee is Technical Committee-39(TC39).

4. Proposed something else [ https://github.com/tc39/proposal-ptc-syntax ]

While apple is against Syntactic tail calls, they’re mainly just opposed to versions of it that would remove/unrequire the tail-call optimisation they already do: https://github.com/tc39/ecma262/issues/535

For the version of it that is backwards compatible, they wouldn’t need to do anything other than recognise it as valid syntax. Their main concern is that it "could add confusion with very little benefit."

The spec for STC has a critique of PTC:

- performance

- developer tools

- Error.stack

- cross-realm tail calls

- developer intent

See: https://github.com/tc39/proposal-ptc-syntax#issues-with-ptc

Apple's 2016 response as to why they won't implement STC is here: https://github.com/tc39/ecma262/issues/535

- STC is part of the spec and will take too long to change.

- Now that they've implemented support for PTC, they don't want to regress web pages that rely on it.

- They don't want to discourage vendors from implementing PTC by agreeing to STC.

- They don't want to introduce confusion.

Some of these arguments about confusion and delays seem wrong hindsight, since on every point things would have been better if they'd just agreed to the compromise of STC.

- It would have been part of the spec years ago

- STC would have had a clear way for web pages to know when tail calls could be relied on (and PTC would have been optional)

- Other vendors didn't implement PTC in any case, despite no agreement on STC

- There's even more confusion as things are now

To cancel a task, you'll have to do that plumbing yourself, and it depends on what you're wanting to cancel. Most libraries provide some sort of mechanism to do the cancelation. The fetch API allows you to pass in an abort controller, which provides a way for you to signal to the running fetch request to abort. setTimeout() has clearTimeout(). In Node, if you read a file as a stream instead of a simple fs.promises.readFile(), you'll have the power to just stop trying to grab more data from the stream. Each async API has its own way to enable aborting (or, sometimes it doesn't provide any way to abort at all). There's unfortunately no standard way to handle aborting (though there is this stalled JavaScript proposal that attempted to standardize an abort system).

Finally, one other related and important concept is the token-based cancelation of asynchronous subscriptions (the current TC39 proposal), which I plan to cover later. If you find these topics interesting, consider following me on Twitter for any updates.