One might argue to make that function just -> Never and that's fine for this function, but we also use undefined() -> T while prototyping sometimes, this ticket is more about the general type inference behavior.

@swift-ci create

Interesting observation, adding a `T.Type = T.self` parameter actually helps the inference get it right. A bit weird that it makes a difference tbh, but it solves the Void inference case:

without:

  1> func TODO<T>() -> T { fatalError() }
  2> func x() { TODO() }
error: repl.swift:2:12: error: generic parameter 'T' could not be inferred
func x() { TODO() }
           ^

with:

  1> func TODO<T>(t: T.Type = T.self) -> T { fatalError() }
  2> func x() { TODO() }
error: repl.swift:2:12: error: generic parameter 'T' could not be inferred
func x() { TODO() }
           ^

Those two should be equivalent for type inference imho, but I guess that's a workaround.

For Void-returning functions that have single-expression bodies, the single expression is not parsed as an implicit return statement. This exception is intentional and justified in the proposal for implicit return statements.

One workaround is to coerce the result of TODO() to Void, e.g.

func boom() {
    TODO("once #​2222 is solved") as Void
}

Thanks for pulling up the SE, Holly! I missed that exception there.

I see... A bit disappointing that there's exceptions like that to be honest, but ok, seems to be as it was designed.

For context: other languages with return inference handle this case well, without burdening the developer with edge cases (e.g. Scala), so it was a surprise to me. Perhaps some time it could be ironed out, we'll see.