Re: try/catch/else

On 02/08/2018 06:50, Alan Plum wrote: I realise there is some ambiguity in using the else keyword for this (though I can't think of a meaningful opposite of "catch" either). Indeed. You can't use 'else' without breaking existing behavior. For example: if (foo) try {...} catch (e) {...}

Re: Suggestion: Destructuring object initializer.

The difference between `{...a, ...b}` and `Object.assign({}, a, b)` is the same as the difference between `[a, b]` and `new Array(a, b)`. The latter cases (correct me if I'm wrong) rely on dynamic lookup of names and methods, whereas the former cases, as syntactical constructs, have statically

Re: async/await -> await/async: a simpler, less error-prone async syntax

FTR, TypeScript and Flow (I assume) know when the static type of a function call (or any other expression that evaluates to a Promise) is a Promise, and if you try to use it as if it wasn't, it will almost surely be a type error. On 12 February 2018 at 10:27, Алексей wrote: >

Re: Suggestion: Destructuring object initializer.

Thanks for reading my post down to the part that caught your attention. Concerning this: > engines can optimize for objects that are not referenced elsewhere by not actually copying them, something harder to do with `Object.assign`.\* I'm intrigued; please elaborate. I had thought that `{...a,

Re: Re: Proposal to add keyword "nowait"

It doesn't decide the whole problem. Because what to do with built-in api which returns promises (like `fetch`)? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal to add keyword "nowait"

I think it should not be hard to implement at least for explicitely async functions. Of course it will miss non-async that return promises. But you can mark them as async. For example we are doing on each function that could return promise even if it doesn't use await. But even without it that

Re: Re: Proposal to add keyword "nowait"

I’m not sure that it will be simply to implement. Because not all possible to analyze without execution. I offer to use `nowait` there where calls will return promise, but it i’m not sure that promises always can detect just via parsing of source code.

Re: Proposal to add keyword "nowait"

I would solve such issue by having transpile step that inserts assertions everywhere in dev enviroment (and don't add them in production env). On Mon, Feb 12, 2018 at 6:41 AM, Александр Ефремов wrote: > Sometimes when create the async functions forget to add await and later

Re: async/await -> await/async: a simpler, less error-prone async syntax

On Mon, Feb 12, 2018 at 11:27 AM, Алексей wrote: > I think there is something we could have right now to solve the problem of > missing `await` without changes to the ES - it should be collored > differently in IDE or texteditor you are using. Not like an error - because > it's

Re: Re: Proposal to add keyword "nowait"

Hm, yes, you are right. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal to add keyword "nowait"

On Mon, Feb 12, 2018 at 10:28 AM, Александр Ефремов wrote: > Hm, yes, you are right. > That’s https://eslint.org/docs/rules/require-await > Thank you very much. > In the next I will be more dig. > That just warns you if you've made a function `async` pointlessly (which may

Re: Re: Proposal to add keyword "nowait"

Hm, yes, you are right. That’s https://eslint.org/docs/rules/require-await Thank you very much. In the next I will be more dig.___ es-discuss mailing list es-discuss@mozilla.org

Re: async/await -> await/async: a simpler, less error-prone async syntax

I think there is something we could have right now to solve the problem of missing `await` without changes to the ES - it should be collored differently in IDE or texteditor you are using. Not like an error - because it's actually not. But to be obvious that "here" and "here" you have an `async`

Re: Proposal to add keyword "nowait"

You could have a rule that could enforce always using `return await` in try/catch blocks in async functions. The `nowait` equivalent would be disabling that rule for that line. For the `nobreak` example I gave this actually exists (the rule is called `no-fallthrough` and could be disabled per

Re: Re: Proposal to add keyword "nowait"

Sorry, I didn’t read it yet. But will be later of course. And I understood about actual proposal. Thanks. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal to add keyword "nowait"

@Александр Ефремов - Have you read through the previous discussion I linked? https://esdiscuss.org/topic/async-await-await-async-a-simpler-less-error-prone-async-syntax It seems to me it's exactly what you're describing (other than the keywords involved). Not sure there's much to gain from

Re: Re: Proposal to add keyword "nowait"

Maybe it should be separate safely mode (similar to `use strict;` for example). Where should includes such proposes and maybe more. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal to add keyword "nowait"

I don’t understand how you offer to decide it via eslint. Because without additional keyword (`nowait`) it’s impossible to controlling. But if doesn’t add `nowait` keyword to spec then anyone should to remove it (i.e. babel transpiling for example). I wanted that it was part spec. And `nobreak`

Re: Proposal to add keyword "nowait"

It sounds like what you want is basically a built-in syntax requirement that replaces what should be an eslint rule. For consistency this would mean JS should also have the keyword `nobreak` to prevent accidental switch/case fallthrough. Or you could just write an eslint rule for this (if one