Rule request: [no-async-without-await] Functions marked async must contain an await or return statement

[pm-dev]

New Issue Checklist

• Updated SwiftLint to the latest version
• I searched for existing GitHub issues

New rule request

Disallow async functions which have no await expression.

1. Why should this rule be added? Share links to existing discussion about what
   the community thinks about this.
   async functions that don't suspend contradict the Swift Concurrency documentation which specifies they are able to suspend partway through execution.
   Asynchronous functions that don’t use await can cause confusion in that a programmer awaiting such a function may assume it's guaranteed to execute its work in the background. Although such an assumption is a fundamental misunderstanding of Swift Concurrency, there are plenty of examples.

Async functions without await are a common and unintentional result of refactoring.

2. Provide several examples of what would and wouldn't trigger violations.

Pass:

func f() async {
    await fetch();
}

Fail:

func add(a: Int, b: Int) async {
    return a + b
}

4. Should the rule be configurable, if so what parameters should be configurable?
   There may be edge cases where async without await is appropriate that I'm not thinking of.

5. Should the rule be opt-in or enabled by default? Why?
   Enabled by default
   I believe this rule would be fast, is not prone to false positives and is general consensus.

Linters for other languages have this rule:
TS Lint
ES Lint

[jshier]

Async functions without awaits are entirely appropriate, as they can be used to run synchronous code in the background. Barring any enclosing actor scope (isolation), your add example will be run on the default executor, making it easy to ensure it will run in the background. You can do the same thing from within an actor by marking the function nonisolated, which will ensure it hops out of the current isolation onto the default executor.

If this is added it should certainly not be enabled by default.

[pm-dev]

@jshier you're suggesting async can be added to run the function in the background, yet admit asynchronous functions aren't guaranteed to run in the background. This is why I believe this rule is important, to avoid this confusion.

Until Swift 5.9 and custom executors, it's not possible to use Swift Concurrency to guarantee code is run in the background.

[jshier]

If defined outside an actor context, async does guarantee background execution (execution on the default executor, i.e. the concurrency thread pool). If defined in an actor context, async still forces concurrent execution back onto the same context. Both of these are useful behaviors. Even in an actor context where the method will execute on the actor, this warning doesn't seem useful, as that fact should be self evident if you're familiar with Swift concurrency (e.g. unlabeled async functions will execute on their inherited actor context, if any, or the default executor), so I'm not sure what it would be protecting against.

[pm-dev]

Execution on the default executor != execution in the background. Today that may be the case, but the way the cooperative thread pool works is an implementation detail that is not exposed and could change in the future/on more constrained systems. Swift Concurrency provides an abstraction that doesn't have a concept of "background". Currently (Until swift 5.9) if you want to guarantee code is executed off the main thread (i.e. the background) you need to drop down to GCD or Threads.

If this rule is not useful, then why shouldn't every function be marked as async?

[jshier]

Yeah, that's not a distinction Swift concurrency makes, so I think you're pretty off base on user expectations here. Why would anyone expect that when, given your definition, it's not even possible right now?

In any case, I've laid out my reasoning, it's up to the maintainers now.

[pm-dev]

that's not a distinction Swift concurrency makes

I'd argue it does make that distinction by intentionally not documenting whether code is run in the background:

Swift's concurrency design is intentionally vague about the details of how code is actually run.

Source

My response to your original comment only intended to explain why the one example you provided against this rule is invalid. Adding async to a function without awaits is not a way to run synchronous code in the background.

[SVGreg]

Function declaration represents interface, whereas it's content is implementation.

protocol MyAsyncProtocol {
    func doSomething() async
}

class ImpOne: MyAsyncProtocol {
    func doSomething() async {
        await useAsyncFunction() // Is Ok - using await
    }
}

class ImpTwo: MyAsyncProtocol {
    func doSomething() async {
        useSyncFunction() // Is also Ok - not to use await if not needed
    }
}

[pm-dev]

☝️ valid