Rule for async without await

[ryanc-bs]

Hi, I'm wondering what you think about adding a rule to catch async functions that have no await statements - and which could therefore be changed into sync functions for a small performance and simplicity gain.

It could work in the same way as this no-async-without-await rule in TSLint: https://palantir.github.io/tslint/rules/no-async-without-await/#:~:text=Marking%20a%20function%20as%20async,keyword%20is%20there%20by%20mistake.

Of course there may be instances where a function needs to be async to satisfy some external interface. But in all other cases, it would be useful to have a way to scan for pointless async functions.

I don't think an auto-fix would be very simple since the call sites also need to be updated, but flagging as a warning for manual fixing would be helpful.

[jakkdl]

This kind of exists in the form of ASYNC910, though that will flag a lot more than just functions without await and so might not be relevant for you.
Ruff does have unused-async, though you'll need to run with --preview to get it.

Agree that autofix is not really on the table.

But I'm not opposed to adding it to flake8-async itself, and even for ruff it kind of fits better among the other async rules than randomly among their own. Implementing it should be straightforward, only complication would be if we want it to interact with ASYNC9xx and suppress ASYNC9xx if async-no-await is raised.
@Zac-HD for a second opinion

[ryanc-bs]

Thanks, I did not know about RUF029. Something I noticed while trying that is that is only seems to work for simple functions and not for methods on a class - would be great to be able to lint both of these.

[Zac-HD]

• I think this would need to be an opt-in rule, and thus doesn't need to interact with others at all (users can be responsible for choosing a satisfiable configuration, so we can just note "conflicts with $rule and $rule, choose one")
• I'd bet it skips methods on a class because it assumes that those are satisfying some external interface, which is my experience - having to manually ignore those would be very annoying.

[jakkdl]

I suppose we could have two rules then, one for functions and one for class methods, with accompanying blurbs about their optional-ness.

[TeamSpen210]

One other situation that might be worth excluding is functions with decorators applied, since those probably also expect a specific interface. Although of course many don't or are adaptive between sync/async.

[jakkdl]

uh... turns out there's already a ~finished PR implementing this 🙃
#309
and #253 as the associated issue

[jakkdl]

Past me concluded there's a "cray false alarm rate" for class methods, so I'll stick with only doing this for functions.
If you really do want this you could run ASYNC910/ASYNC911 as a one-off.

One other situation that might be worth excluding is functions with decorators applied, since those probably also expect a specific interface. Although of course many don't or are adaptive between sync/async.

#309 has support for no-checkpoint-warning-decorators for decorators where you want to suppress 910, 911, and 124 :)