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

[Craig Cruden]

A guard is an interesting idea as it is really just saying to not perform the function if.

Of course a lot of the cases you are guarding against is where a value is null/nil and would have caused an abend if passing a null.

Now with options though if you have one option -> map -> new Option you would not necessarily have the same issue (not saying never).


> On 2015-12-21, at 22:36:19, Sean Heber <sean at fifthace.com> wrote:
> 
> In my experience, early returns usually reduce spaghetti and it is why I’m a huge fan of guard since it encourages this pattern. In an effort to return as early as possible, my conditions usually coalesce into small nuggets of logic that all terminate with a return which makes them really easy to identify and it seems to reduce the nesting depth of statements. When stepping through code in the debugger, it’s easy to spot a problem, too, if it hits a return I didn’t expect rather than weaving down a bunch of conditional code and maybe going into one branch, skipping over another, etc. all in an effort to reach the "one true return" at the end.
> 
> l8r
> Sean
> 
>> On Dec 21, 2015, at 7:31 AM, Craig Cruden via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> The difference between issuing return embedded in multiple locations to reduce verbosity is actually slightly more than extra verbosity it is actually a different execution path.
>> 
>> In my last example (Scalaish).  The last and only expression in the function is the whole match case - it terminates at the end of the function.
>> 
>>  def f2(input: Integer) : Integer = {
>>    input match {
>>        case _ if input > 10 => 10
>>        case _ if input < 0  => 0
>>        case _ => input
>>    }
>>  }
>> 
>> Whereas if you sprinkle in returns as such, you are actually changing the execution path:
>> 
>>  def f2(input: Integer) : Integer = {
>>    input match {
>>        case _ if input > 10 => return 10  <— function terminates here
>>        case _ if input < 0  => return 0  <— function terminates and here
>>        case _ => return input  <— <— function terminates and here
>>    }
>>  }
>> 
>> A move towards spaghetti like code.
>> 
>> Now if you were to add an extra expression like using an intermediate value.
>> 
>>  def f2(input: Integer) : Integer = {
>>    let x = input match {
>>        case _ if input > 10 => 10  // no longer terminates here
>>        case _ if input < 0  => 0  // no longer terminates here
>>        case _ => input   // no longer terminates here
>>    }
>>    x /2  // or return x/2
>>  }
>> 
>> You would have had to go back and modify the original execution path with all the embedded returns which can also be a source of unwanted defects if one is missed (in larger functions).
>> 
>> 
>>> On 2015-12-21, at 3:29:27, Radosław Pietruszewski <radexpl at gmail.com> wrote:
>>> 
>>> I honestly don’t have a problem with having to say `return` inside functions. That’s not necessarily a -1, but I’m reluctant to say +1 when _even I_ don’t really have the problem with extra verbosity.
>>> 
>>> *However*, as others pointed out, having to type `return` is a bit tiring in the context of a computer property’s “get”:
>>> 
>>>> var twiceSomething: Int { self.something * 2 }
>>> 
>>> — Radek
>>> 
>>>> On 19 Dec 2015, at 14:30, Craig Cruden via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> 
>>>> When writing short functional code in a function it would be nice if the return keyword were an optional keyword. 
>>>> 
>>>> Just return the last evaluated expression.
>>>> 
>>>> 
>>>> i.e.
>>>> 
>>>>    func flipFunc<T, U>(arg1: T, arg2: U) -> (U, T) {
>>>>        (arg2, arg1)
>>>>    }
>>>> 
>>>> 
>>>> The keyword return would still be there for breaking out of a function.
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>