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 <[email protected]> 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 >> <[email protected]> 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 <[email protected]> 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 >>>> <[email protected]> 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 >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
