<p>In a lot of modern languages (such as Python), asynchronous functions (those that return coroutines) must be explicitly marked as such:</p>
<pre><code>async function foo():
    pass
</code></pre>
<p>Is there any specific reason for this, and if so are there any alternatives?</p>

<syntax><functions><async>
Must async functions always be marked as such?
CC BY-SA 4.0
2023-05-18T11:51:05.693Z
“Primarily python” — off the top of my head, I don’t know of any language with an `await` operator that _doesn’t_ require this.
Bbrk24
CC BY-SA 4.0
2023-05-18T11:52:04.673Z
As opposed to what, inferring `async`ness from the use of `await`s in the body? Though it's not like that isn't how generators work, it's still pretty clear why that would be undesirable...
Unrelated String
CC BY-SA 4.0
2023-05-18T11:54:13.533Z
@UnrelatedString Clarified that I'm asking for alternatives, if any.
Ginger
CC BY-SA 4.0
2023-05-18T11:55:28.537Z
Does “just don’t have await at all” count as a valid alternative? Swift only had callbacks until late 2021 when they finally added `await`.
Bbrk24
CC BY-SA 4.0
2023-05-18T16:16:44.627Z
There's no `async` modifier in C++, a function is a coroutine iff it contains at least one of `co_await`, `co_yield` or `co_return`. This has the disadvantage that a coroutine can easily stop being one if you refactor code and remove all `co_` keywords.
zdimension
CC BY-SA 4.0
2023-05-18T19:16:17.577Z
[this](https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/) blog post by Bob Nystrom about colours is classic.
Viola
<p>Marking asynchronous functions <code>async</code> is indeed unnecessary in many languages, as mousetail's answer explains. However, in C#, the <code>async</code> function marker keyword was needed for another reason: to to maintain backwards compatibility, in case an existing (non-async) method used <code>await</code> as a variable or method name. So <code>await</code> would only be treated as a keyword if it was in a method marked <code>async</code>. More details are given in <a href="https://learn.microsoft.com/en-us/archive/blogs/ericlippert/asynchrony-in-c-5-part-six-whither-async" rel="noreferrer">this MSDN blog post</a>.</p>
<p>I speculate that the <code>async</code>/<code>await</code> syntax was then simply copied into other languages like Python and JavaScript without too much thought, which is why it's present there, even when they may not have the same backwards-compatibility goals, or a better new design could've been used. But I can't be sure on that.</p>

CC BY-SA 4.0
2023-05-18T12:06:01.453Z
2023-05-18T12:14:24.630Z
2023-05-18T12:14:24.630Z
pxeger
CC BY-SA 4.0
2023-05-18T13:10:41.113Z
I’d argue that it’s even more necessary in JS than C#: C# versions both the compiler and runtime, but JS needs to support decades-old code.
Bbrk24
<h2>No</h2>
<p>There are various solutions to avoid needing to mark functions as async.</p>
<h3>Making every function async by default</h3>
<p>Some languages work this way. All functions return promises in theory and can use your await syntax.</p>
<p>This is what Go does.</p>
<h3>Making functions async if they contain <code>await</code></h3>
<p>Since a non-async function can't await, it makes sense to just automatically make functions with that syntax async. This is how generators work in Python, including <code>yield</code> makes them a generator.</p>
<p>Also if you don't have <code>await</code> or insert it implicitly there is no way to know.</p>
<p>Disadvantage is the return type changes depending on syntax. A stub method now returns the wrong type if it has no <code>await</code>.</p>
<h3>Making functions async depending on their return type</h3>
<p>If your language is statically typed and requires functions to have a return type specified, you could use that to detect if a function is async. Requires no special syntax.</p>
<p>Disadvantage is if your function returns a literal promise that wouldn't be possible. You could have separate types for automatic promises and manually created promises to resolve this issue, but then you have the whole complexity of converting between them and it might not be worth it.</p>

CC BY-SA 4.0
2023-05-18T11:55:54.173Z
2023-05-18T12:28:58.147Z
2023-05-18T12:28:58.147Z
mousetail 'he-him'
CC BY-SA 4.0
2023-05-18T11:59:15.607Z
Of course, if Python inferred async from await, they could also add `await pass` or something to that effect.
Bbrk24
CC BY-SA 4.0
2023-05-18T12:03:32.817Z
Yep, but it's a bit annoying. I've had this problem with generators where even throwing a `NotImplementedException` immediately is still a type error because it won't return a generator without a `yield`. A `await pass` could give a potential syntax for async functions but still annoying to need to write code after the exception throw to make it work properly
mousetail 'he-him'
CC BY-SA 4.0
2023-05-18T12:07:46.253Z
@Bbrk24 what is the difference of always having to add `await` vs always having to add `async`? Seems like fully equivalent, you just swap what you have to add, but in either case you need to add *something*.
VLAZ
CC BY-SA 4.0
2023-05-18T12:08:51.197Z
@VLAZ The main benefit of async functions is that you are allowed to use the `await` keyword. So you still need a keyword but it's one you need anyways
mousetail 'he-him'
CC BY-SA 4.0
2023-05-18T12:10:31.923Z
The first option is discussed in excellent detail in the blog post [What colour is your function?](https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/).
pxeger
CC BY-SA 4.0
2023-05-18T12:10:47.493Z
@mousetail OK, but you talked about stubs which was also the contest of Bbrk24's comment. If we circle around to non-stub functions/methods then - sure, `await` can be used as a marker.
VLAZ
CC BY-SA 4.0
2023-05-18T12:12:32.347Z
@VLAZ Yea for stubs my second option is clearly worse than just marking the function `async`.
mousetail 'he-him'
# Must async functions always be marked as such?
Posted by: username_0 on 2023-05-18
In a lot of modern languages (such as Python), asynchronous functions (those that return coroutines) must be explicitly marked as such:
async function foo():
    pass

Is there any specific reason for this, and if so are there any alternatives?
**Tags:** syntax functions async
> **Comments:**
> **username_1**: “Primarily python” — off the top of my head, I don’t know of any language with an `await` operator that _doesn’t_ require this.  
> **username_2**: As opposed to what, inferring `async`ness from the use of `await`s in the body? Though it's not like that isn't how generators work, it's still pretty clear why that would be undesirable...  
> **username_0**: @UnrelatedString Clarified that I'm asking for alternatives, if any.  
> **username_1**: Does “just don’t have await at all” count as a valid alternative? Swift only had callbacks until late 2021 when they finally added `await`.  
> **username_3**: There's no `async` modifier in C++, a function is a coroutine iff it contains at least one of `co_await`, `co_yield` or `co_return`. This has the disadvantage that a coroutine can easily stop being one if you refactor code and remove all `co_` keywords.  
> **username_4**: [this](https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/) blog post by Bob Nystrom about colours is classic.  
---
## 2 answers
### Answer by username_6 on 2023-05-18. Score: 8
## No

There are various solutions to avoid needing to mark functions as async.

### Making every function async by default

Some languages work this way. All functions return promises in theory and can use your await syntax.

This is what Go does.

### Making functions async if they contain `await`

Since a non-async function can't await, it makes sense to just automatically make functions with that syntax async. This is how generators work in Python, including `yield` makes them a generator.

Also if you don't have `await` or insert it implicitly there is no way to know.

Disadvantage is the return type changes depending on syntax. A stub method now returns the wrong type if it has no `await`.

### Making functions async depending on their return type

If your language is statically typed and requires functions to have a return type specified, you could use that to detect if a function is async. Requires no special syntax.

Disadvantage is if your function returns a literal promise that wouldn't be possible. You could have separate types for automatic promises and manually created promises to resolve this issue, but then you have the whole complexity of converting between them and it might not be worth it.
> **Comments:**
> **username_1** (2023-05-18): Of course, if Python inferred async from await, they could also add `await pass` or something to that effect.  
> **username_6** (2023-05-18): Yep, but it's a bit annoying. I've had this problem with generators where even throwing a `NotImplementedException` immediately is still a type error because it won't return a generator without a `yield`. A `await pass` could give a potential syntax for async functions but still annoying to need to write code after the exception throw to make it work properly  
> **username_7** (2023-05-18): @Bbrk24 what is the difference of always having to add `await` vs always having to add `async`? Seems like fully equivalent, you just swap what you have to add, but in either case you need to add *something*.  
> **username_6** (2023-05-18): @VLAZ The main benefit of async functions is that you are allowed to use the `await` keyword. So you still need a keyword but it's one you need anyways  
> **username_5** (2023-05-18): The first option is discussed in excellent detail in the blog post [What colour is your function?](https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/).  
> **username_7** (2023-05-18): @mousetail OK, but you talked about stubs which was also the contest of Bbrk24's comment. If we circle around to non-stub functions/methods then - sure, `await` can be used as a marker.  
> **username_6** (2023-05-18): @VLAZ Yea for stubs my second option is clearly worse than just marking the function `async`.  
---
### Answer by username_5 on 2023-05-18. Score: 6
Marking asynchronous functions `async` is indeed unnecessary in many languages, as mousetail's answer explains. However, in C#, the `async` function marker keyword was needed for another reason: to to maintain backwards compatibility, in case an existing (non-async) method used `await` as a variable or method name. So `await` would only be treated as a keyword if it was in a method marked `async`. More details are given in [this MSDN blog post](https://learn.microsoft.com/en-us/archive/blogs/ericlippert/asynchrony-in-c-5-part-six-whither-async).

I speculate that the `async`/`await` syntax was then simply copied into other languages like Python and JavaScript without too much thought, which is why it's present there, even when they may not have the same backwards-compatibility goals, or a better new design could've been used. But I can't be sure on that.
> **Comments:**
> **username_1** (2023-05-18): I’d argue that it’s even more necessary in JS than C#: C# versions both the compiler and runtime, but JS needs to support decades-old code.  
---
