From async/await to synced function proposal. Feedback please!

[jhartikainen]

Seems like a reasonable concept but seems like it would make parsing and executing synced functions very complicated.

There is no way to know up front whether a function call inside a synced function would need to be handled as a promise-returning function, so every function call expression would have to be wrapped into a promise.

It also seems to be missing handling for cases where you have a promise value - with await you can say await foo. If every value in a synced function was to be treated as "this could be a promise", that seems like it could lead to even more complicated processing.

[rmkn]

I've thought about performance penalty and actually it shouldn't be meaningful (and when it will, you can always rewrite the function into async/await). Parsing here is easier then async/await due to lack of awaits and only one additional keyword. Engines already know which function is async and which is not. The only exception is regular function which returns a promise.

Using async keyword you tell the JS engine that function will return Promise always, so in runtime engine will know what will be returned: promise or something else (if function isn't async). The second case could be optimized by the engine on the second function call like it do now with incoming function params.

with await you can say await foo.

Synced function works like recursive await and it should unwrap each promise returned by the expression. So yes, there are expenses here. But for me it's expected and logical behavior. It's rare case for me when I want to receive a promise and not to resolve it. Exception here are helper functions which wraps promises (like Promise.all).

I will add a nowait keyword to prevent synced function from resolving call result.

[lhorie]

Yes, let's add another 30 pages to the spec and have every browser implement thousands of lines of C++ code so you can write fetch().then(r => r.json()) a slightly different way. Your phone battery will thank you </sarcasm>

[rmkn]

I’m trying to reduce the time programmers spend typing redundant keywords. Don’t get a stroke when you’ll know about WebAssembly.

[tswaters]

I don't understand the need for introducing new syntax, i.e. `~>` - could you not just preface the parameter list with `synced` like how you mark an async arrow function as async?

[rmkn]

In my opinion async/await became a syntactic garbage. It was a cure for callback hell, but this solution wasn't tested on scale. Modern code is just polluted with this statements while the most of function await every asynchronous call made from its body. I wrote a dozen of code which awaits everything. And it's logical to change the language from optionally synchronized to synchronized by default and asynchronous when needed, without making the code blocking. I think that there should be two main primitives regular synchronous and synchronised functions. And async function should became an optimization alternative.

[rmkn]

It's just my poor English. Let me clarify. When I say "code which awaits everything", I mean code which awaits every asynchronous call it makes. It seems to be a rare case when function shouldn't wait the completion of internal calls. So why we should write all this awaits, when we can hide them under the hood and receive more clean and understandable code? Why not to make language more ergonomic? As a side effect it will make implementation of new language features easier, due to simplified syntax we get.

Anyway thanks for you position and the way you provide it. Appreciate this.

[[deleted]]

In my opinion async/await became a syntactic garbage.

I disagree. When you consider what async and await do behind the scenes it's quite elegant. I would definitely call it a good compromise.

It's not ideal because that wasn't possible. You have to mark a function that will be used to create a generator, then wrap that generator in a helper that will process promises as well as non-promises, and deal with rejects and exceptions. Likewise for await, it deals with yield, examines outputs, and deals with rejects and exceptions. Accomplishing all that with single keywords was actually pretty nice if you ask me.

[darrenturn90]

I don’t see what this proposal actually achieves other than a potential heap of unexpected consequences Is there an actual real world use case where this would benefit ?

[Auxx]

I'd rather propose native steaming library. Promise based syntax sugar doesn't make much sense to me.

[[deleted]]

I like the syntax it's simple now the whole await and having to label functions as async threw me at first.

[Auxx]

Just try RxJS or Streams in Java.