Allow implicit returns in all functions in Swift

Originator:listrophy
Number:rdar://17129390 Date Originated:6/3/2014
Status:Closed Resolved:WONTFIX
Product:Developer Tools Product Version:
Classification:Feature (new) Reproducible:Always
 
Apple's response:

We made a very conscious decision not to do this.  The savings is very trivial compared to the loss of clarity.

###

Summary:
Closures in Swift allow an implicit return if the body is a single expression. In multiline closures and named functions, the `return` keyword is currently required. This doesn't seem necessary.

Steps to Reproduce:
1. Write a function like this:
func square(val: Int) -> Int {
  val * val
}
2. Or write a closure like this (wrapped in the "addSome" function for demonstration purposes only):
func addSome(addend: Int) -> (Int -> Int) {
  return {(val: Int) -> Int in
    let foo = "bar"
    val + a
  }
}

Expected Results:
Both functions should compile correctly.

Actual Results:
In example 1, we receive a "Missing return in a function expected to return 'Int'" compiler error, and in example 2, we receive a "Missing return in a closure expected to return 'Int'" compiler error.

Version:
Xcode 6.0 beta (6A215I)

Notes:
Basically, I feel that the `return` keyword is unnecessary in many cases. It doesn't need to be removed from the language, as it's useful for short-circuiting in edge cases (as one example), but it shouldn't be needed in normal usage.

Comments

Yes please :)

@thebuckley's rationale for not having this feature simply highlights another issue with Swift. if should be an expression rather than a statement just as it is in other languages such as Haskell, Erlang, ML, Ruby, Rust, etc.

No implicit returns, please

As someone in now way associated with Apple or the development of Swift, I would prefer that implicit returns not be added to Swift. In the examples provided, it's not so bad, but in larger functions, it can get confusing. Implicit returns have caused me quite a few headaches in Ruby code. Swift is a bit better in this regard, since you have to declare a return type, so you won't accidentally return a closure, bit it's liable to be confusing to those learning the language (which is, right now, almost everybody). For example, a learner might see the first version of your square function and assume they can do something like this.

func factorial(val: Int) -> Int { if (val == 1) { 1 } else { val * factorial(val - 1) } }

They'd be greeted with a compiler error because they lacked a return statement.

In general, I prefer the explicit return because I think it's better for a programming language to be explicit. I wouldn't complain too much if explicit returns were removed in favor of implicit returns though, since small optional language features like this encourage programmers to argue over style, even when the issue isn't that important.

By thebuckley at June 4, 2014, 1:13 a.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!