[swift-evolution] [Proposal] function "return" optional keyword.

[Patrick Gili]

I have to agree with everything Ilya has mentioned in her response.

It comes down to readability. Omit the "return" keyword from a function and points that the function returns become hard to see. The optional "return" keyboard in Ruby is one of the few features of Ruby that I genuinely dislike for this reason. Of course, Ruby makes it more difficult because it doesn't type methods.

Cheers,
-Patrick

> On Dec 20, 2015, at 7:11 AM, ilya via swift-evolution <swift-evolution at swift.org> wrote:
> 
> -1 on inferred return type and omitting return with func
> 
> Both features are actually available in the language as-is, just not with the func keyword:
> 
> let someInferredFunction = { _ in 5}  // () -> Int
> 
> When teaching Swift we actually teach func + return keywords together, they make it easy to see all possible return paths from a function.
> 
> And we recommend using func instead of a closure when there is a multiline body with control statements. Having implicit return in that case hurts readability.  For example, out of three possible return points within this function only one is not marked with return:
> 
> func f(input: Int) -> Int {
>     if input > 10 { 
>         return 10 
>     }
>     if input < 0 { 
>         return 0 
>     }
>     input
> }
> 
> 
> +1 on omitting return from var {} declaration, those methods look like closures and will often be one-liners.
> 
> 
> On Sun, Dec 20, 2015 at 5:29 AM, Craig Cruden via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> I looked at the discussion and it looked like they were discussion two things combined.
>    - inferred return type (on function signature) 
>    - and omitting return on the return.
> 
> I agree with Chris on the fact that the function should have the type of return specified on the signature and not inferred since it is useful for API documentation to know that ahead of time on a strongly typed language.
> 
> What is not necessary is actually forcing people to type return “x” on the last line - since “return” is rather redundant and clutter for those people of a functional programming paradigm point of view.
> 
> 
>> On 2015-12-20, at 4:15:15, Stephen Christopher via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> The discussion I was remembering, comment courtesy of Chris: 
>> https://devforums.apple.com/message/1014317#1014317 <https://devforums.apple.com/message/1014317#1014317>
>> 
>> (linked from https://devforums.apple.com/thread/255242 <https://devforums.apple.com/thread/255242>)
>> 
>>  _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151220/f998b876/attachment.html>