Proposal to add keyword "nowait"

# Александр Ефремов (10 months ago)

Sometimes when create the async functions forget to add await and later such mistake difficult to find. Maybe would be better always demand to add keyword nowait to calls returning promises which we don't plan to wait. But if that keyword and await keyword no exists then throw the error.

# Peter Jaszkowiak (10 months ago)

This certainly doesn't sound backwards compatible. Also, this is something that type checking systems (like typescript and flow) are very good at catching.

# Александр Ефремов (10 months ago)

Yes, agree that it doesn't backwards compatible. But type checking systems (like typescript and flow) it's overhead for fast development.

# Isiah Meadows (10 months ago)

Yeah, and given it's the default, I'm not persuaded of the benefit to be gained here.

(Most feature requests like these in my experience come from such users who use async/await without learning promises first. Without that knowledge, people typically don't get that it's merely syntax sugar for the common case, and they rarely understand that async/await is not obligatory to use async functions. When users realize that, this really does begin to seem superfluous, since the absence of a keyword or .then/.catch implies you're not awaiting.)

# Александр Ефремов (10 months ago)

Sorry, but I didn’t understand you sentence. And I have knowledge in the promises of course.

# T.J. Crowder (10 months ago)
# Александр Ефремов (10 months ago)

Yes, I was mistaken. That is possible only to do via type checking systems. it's not work of javascript of the interpreter. Thanks for explanations.

# Александр Ефремов (10 months ago)

I just considered this proposal in a context of node.js environment. I write microservices which execute requests to database and other microservices. All such requests are asynchronous. Therefore I execute them in body of async function. And sometimes I forget to add await for such operations. I thought that possible to implement that only for async await and didn't know that it transpiling to promises queue. I right understand that general problem in that?

But also is need sometimes don't wait ending of the call. For example if on the browser side we execute operation adding row to the any list and after that to get actual list rows we execute still one request to the backend then we can don't wait ending that query and return to the list rows page for example. I.e. in such cases result of that promise isn't important in context that function.

# Alan Plum (10 months ago)

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 doesn't already exist).

# Александр Ефремов (10 months ago)

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 also is good proposes.

# Александр Ефремов (10 months ago)

Maybe it should be separate safely mode (similar to use strict; for example). Where should includes such proposes and maybe more.

# T.J. Crowder (10 months ago)

@Александр Ефремов -

Have you read through the previous discussion I linked? 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-discussing it (as opposed to moving forward with an actual proposal).

-- T.J. Crowder

# Александр Ефремов (10 months ago)

Sorry, I didn’t read it yet. But will be later of course. And I understood about actual proposal. Thanks.

# Alan Plum (10 months ago)

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 case individually to allow omitting the break keyword).

# Александр Ефремов (10 months ago)

Hm, yes, you are right. That’s require-await eslint.org/docs/rules/require-await

Thank you very much. In the next time I will be more dig.

# T.J. Crowder (10 months ago)

On Mon, Feb 12, 2018 at 10:28 AM, Александр Ефремов <mr.efrem at gmail.com>

wrote:

Hm, yes, you are right. That’s 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 or may not be because you forgot an await). It won't help you if you have at least one await but have forgotten others.

Static analysis (such as done by ESLint) cannot perfectly solve the problem you and Steven Mascaro are trying to solve: Forgetting awaits in all necessary locations in an async function.

-- T.J. Crowder

# Александр Ефремов (10 months ago)

Hm, yes, you are right.

# Michał Wadas (10 months ago)

I would solve such issue by having transpile step that inserts assertions everywhere in dev enviroment (and don't add them in production env).

# Александр Ефремов (10 months ago)

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.

# Алексей (10 months ago)

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 should hit most of missed await errors

2018-02-12 13:34 GMT+02:00 Александр Ефремов <mr.efrem at gmail.com>:

# Александр Ефремов (10 months ago)

It doesn't decide the whole problem. Because what to do with built-in api which returns promises (like fetch)?