Method returning `throws -> Never` should be callable as `throw method()`, not `try method()`

[MahdiBM]

Method returning throws -> Never should be callable as throw method(), not try method().
This is not the case right now:

struct Err: Error { }

func logThenThrow() throws -> Never {
    ...
    throw Err()
}

throw logThenThrow() /// Error: Call can throw but is not marked with 'try'

func saveInDBThenThrow() async throws -> Never {
    ...
    throw Err()
}

throw await saveInDBThenThrow() /// Error: Call can throw but is not marked with 'try'

Motivation
This is useful in situations where you want to perform some work and only then throw.
Is is still possible right now using the try keyword instead of throw, but that syntax is not as clear as it should be on call-sites.

Solution
If a method returns Never but is still declared as throws, such as throws -> Never, swift compiler should require users to use the throw keyword behind the method name, instead of try.

Alternatives considered

[AnthonyLatsis]

To clarify, are you proposing throw foo() to be syntax sugar for

do {
  try foo()
} catch {
  throw error
}

when foo is marked as throws and never returns?

What would throw logThenThrow() do if logThenThrow doesn’t actually throw?

[MahdiBM]

@AnthonyLatsis em... Not exactly, maybe i should have been more clear although i did try to.

The key thing here is that the function is marked as -> Never. The function never returns, so if it is marked as throws -> Never then the only logical thing for the function output is to throw.

I know it could also crash the app, but first-party Swift libraries already do have a lot of sugar for when a generic type is Never and always makes an assumption that nobody wants their app crashing, and takes Never as It will Never happen.

For example, the following code is valid:

let a: Task<String, Error> = ...
let b: Task<String, Never> = ...

_ = try await a.value
_ = await b.value /// Note no `try`

The implementation knows that b will never throw, so we don't need to try getting it.

So to recap, what i'm asking is for the Swift compiler to let us be more clear and use the throw keyword instead of try when a method marked as throws -> Never, because the function will always throw in a proper app.

[tbkka]

... because the function will always throw in a proper app.

Having throw foo() mean different things depending on the return type of foo() seems like a very bad idea.

[AnthonyLatsis]

So, in other words, you propose throw to behave like try when applied to a call to a throwing function that never returns, except it would trap at runtime if the function call does not actually throw an error?

Supposing there exists a strong and convincing use case for the notion of an always throwing function, I believe it would be more prudent to also have a syntax for expressing this intent or property on the function declaration rather than have the compiler make chancy assumptions, such as whether it is logical for a function to always throw. Syntactic evidence of intent would enable the compiler to emit an error if errors are rethrown from a function that is not marked as always throwing — instead of accepting code that is known to potentially crash at run time — and grant library authors the freedom to decide when this intent is appropriate.

func willThrow() alwaysthrows -> Never { ... }
func mightThrow() throws -> Never { ... }

func test() throws {
  rethrow willThrow() // OK
  rethrow mightThrow() // error
}

---

For example, the following code is valid:

let a: Task<String, Error> = ...
let b: Task<String, Never> = ...

_ = try await a.value
_ = await b.value /// Note no `try`

The implementation knows that b will never throw, so we don't need to try getting it.

At the risk of stating the obvious, await b.value compiles because overload resolution selects the non-throwing value overload defined under Failure == Never:

https://github.com/apple/swift/blob/29acda5136171474e4c4b2ec2f35ed686362e24b/stdlib/public/Concurrency/Task.swift#L215-L233

I think it is important to stress that Never is not receiving any special treatment from the compiler here. It is the prerogative of the API designers to give Never the meaning it has here.

[AnthonyLatsis]

@MahdiBM If you want to bring attention to this idea and discuss it, consider socializing it on the Swift forums. GitHub Issues are great for tracking implementations of formal proposals, but not the best space for discussing and presenting ideas to the Swift community, which is a required and essential step toward proposing user-facing changes.

[MahdiBM]

@AnthonyLatsis

At the risk of stating the obvious ...

Not obvious, but I was aware that these are just some extensions where Failure == Never, and not compiler magic.

@tbkka

Having throw foo() mean different things depending on the return type of foo() seems like a very bad idea.

Can you elaborate why?

depending on the return type of foo()

True, but Never is not any type. It's quite a special type and already gets a decent amount of special treatment from the compiler.

[MahdiBM]

It appears there has been another post in forums about this around a year ago:
https://forums.swift.org/t/methods-that-throw-and-return-never/61715/3

It mentions that one can just return -> any Error instead of throws -> Never, then throw the returned error.
That very obvious solution (that i did kind-of miss, admittedly) solves the problem well enough, but doesn't invalidate this issue.

Why?

• It's semantically incorrect to have func method() throws -> Never then do try method().

Example:

struct Thing {
    func method() throws -> Never {
        throw MyError()
    }

    func doSomething() throws -> String {
        try method()
        /// Don't need to return a string anymore!
    }
}

• It's still semantically more clear to mark a "will always throw" function as throws -> Never ("throws and never returns anything") then call as throw method() than -> any Error ("return an error?! what to do with the error then?! do i log it? do i try to resolve it? do i throw it?").

The way i see this is more of a semantic fix than a language feature.

Though after the obvious solution came up, and after the fact that i can't come up with strong reasons about the semantic problem (they are good/correct reasons, but not strong), i understand that this can look insignificant enough so the team wouldn't prioritize doing it for a while, or even eventually not do it at all and choose another way around the problem.