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