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

[Craig Cruden]

Also since the example rewrite is a single line function it could be rewritten as:

  def f2(input: Integer) : Integer = input match {
    case _ if input > 10 => 10
    case _ if input < 0  => 0
    case _ => input
  }

Even with the overkill of pattern matching it — it still is easy to understand what is being returned without forcing the use of “return” all over the place.



> On 2015-12-20, at 22:30:28, Craig Cruden <ccruden at novafore.com> wrote:
> 
> Having returns all over the place in the middle of the code already is sloppy to my eyes, I prefer to try at all cost to avoid spaghetti like code.  
> 
> The downside of Swift not having everything as a function/expression - or at least other replacements for them is it tends to encourage spaghetti code like the example you are posting.  I also tend to dislike compound/nested if’s where possible sometimes breaking stuff down into other functions scooped within functions.  
> 
> Hence for my example I am going to use the Scala match (which is for pattern matching — i.e. more than just a switch) with guards.  _ = match everything / def is func.
> 
>   def f(input: Integer) : Integer = {
>     input match {
>       case _ if input > 10 => 10
>       case _ if input < 0  => 0
>       case _ => input
>     }
>   }
> 
> The downside of Scala is that it rides on top of the jvm and I would prefer something that compiled using llvm.   Two things that I would like to see for me to be able to replace a jvm solution for server code is clean functional code where you did not have to either do let x then return at the end or random “returns” in the middle of code and of course a nice jdbc (interface standard for SQL databases rather than relying on vendor specific driver code) like standard SQL database interface [which is out of scope for evolution].
> 
> 
>> On 2015-12-20, at 19:11:09, ilya <ilya.nikokoshev at gmail.com <mailto:ilya.nikokoshev at gmail.com>> 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>
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151220/293152f0/attachment.html>