Pitch: Implicit Returns from Single-Expression Functions

[Nevin]

@nate_chandler

To clarify, the backwards compatibility issue is not tied to the func case.

In Swift today, the following is legal code:

func bad(value: Int = 0) -> Int { return 0 }
func bad() -> Never { return fatalError() }

var getBad: Int { bad() }

and the call to bad in getBad resolves to the Never-returning overload.

With the pitched change, the above would remain legal code but get the call to bad in getBad would resolve to the Int returning overload.

True, however the following code is also legal, and resolves to the (Int)->Int overload:

var getBad2: ()->Int = { bad() }

I think it is seriously problematic that the computed property acts differently than the closure here. We have a high bar for source-breaking changes, requiring that the existing behavior is “actively harmful”, and I believe this situation rises above that bar.

A reasonable developer could quite easily write the line you have for getBad, forgetting the return and expecting it to work just like a closure and call the Int-returning overload, only to discover later—hopefully through testing but possibly not until after deploying to clients—that it actually crashes the application at run-time.

This is bad, and should be fixed.