Proposal to add keyword "nowait"
This certainly doesn't sound backwards compatible. Also, this is something that type checking systems (like typescript and flow) are very good at catching.
Yes, agree that it doesn't backwards compatible. But type checking systems (like typescript and flow) it's overhead for fast development.
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.)
Sorry, but I didn’t understand you sentence. And I have knowledge in the promises of course.
Previous discussion: esdiscuss.org/topic/async-await-await-async-a-simpler-less-error-prone-async-syntax
-- T.J. Crowder
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.
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.
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).
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.
Maybe it should be separate safely mode (similar to use strict; for example). Where should includes such proposes and maybe more.
@Александр Ефремов -
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
Sorry, I didn’t read it yet. But will be later of course. And I understood about actual proposal. Thanks.
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).
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.
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
Hm, yes, you are right.
I would solve such issue by having transpile step that inserts assertions everywhere in dev enviroment (and don't add them in production env).
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.
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>:
It doesn't decide the whole problem. Because what to do with built-in api which returns promises (like fetch)?
Sometimes when create the
asyncfunctions forget to addawaitand later such mistake difficult to find. Maybe would be better always demand to add keywordnowaitto calls returning promises which we don't plan to wait. But if that keyword andawaitkeyword no exists then throw the error.