On: Cancelable Promises: Why was this proposal withdra...

[nraynaud]

ah! that seem like the easy stuff.

[ralfn → nraynaud]

But fetch() returns a promise, rather than a handler you can use to cancel the request. So some people wanted to add "cancel" as a third potential state of a promise.

Which smells a bit like a hack to me. Why stop at cancel? The Fetch API shouldnt return a promise, maybe?

But im assuming a lot of people gave it a lot of though. Maybe it is common enough. Maybe it is horrible to implement in a performant way.

But so far the new ES features ive seen should have been critisized more not less. Look at the ugly mistakes that did make it:

    f => { pizza }

Is the block on the right a statement block or an object literal? Its a statement block so if your lambda function returns an object literal than you need to wrap it in a statement block with a return statement. If it is anything else, than you dont.

Thats the horrible crap that actually gets through the proccess. Imagine how naive and broken the propositions must be that get killed?

[EvilTerran → ralfn]

> if your lambda function returns an object literal than you need to wrap it in a statement block with a return statement

Or you can just parenthesise the object literal:

    >>> (x => ({ x }))(23)
    Object { x=23 }

The grammatical ambiguity is unfortunate, sure, but the simplest work-around isn't so bad.

[ralfn → EvilTerran]

If one forgets the (parentheses) you may or may not immediate or later can an error _somewhere_.

It isn't about the workaround -- it's about all the subtle bugs it will introduce in the edge-cases, for example:

     f => () => {}
     f(); // undefined instead of empty object

[010a → ralfn]

It is a statement block. You need to say

    f => ({ pizza })

to get an object literal. This isn't that hard to understand.

[ralfn → 010a]

But it's easy to forget, just once. For example:

    x => () => {}
    x(); // undefined instead of empty object

This can lead to immediate syntax bugs, eventual errors throws and silent semantic errors.

Which reinforces the whole argument that they should think a bit harder about all the new features.