<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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. </div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><div class=""> def f(input: Integer) : Integer = {</div><div class=""> input match {</div><div class=""> case _ if input > 10 => 10</div><div class=""> case _ if input < 0 => 0</div><div class=""> case _ => input</div><div class=""> }</div><div class=""> }</div></div><div class=""><br class=""></div><div class="">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].</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 2015-12-20, at 19:11:09, ilya <<a href="mailto:ilya.nikokoshev@gmail.com" class="">ilya.nikokoshev@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">-1 on inferred return type and omitting return with func<div class=""><br class=""></div><div class=""><div class=""><div class="">Both features are actually available in the language as-is, just not with the func keyword:</div><div class=""><br class=""></div><div class="">let someInferredFunction = { _ in 5} // () -> Int</div></div><div class=""><br class=""></div><div class="">When teaching Swift we actually teach func + return keywords together, they make it easy to see all possible return paths from a function.</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">func f(input: Int) -> Int {</div><div class=""> if input > 10 { </div><div class=""> return 10 </div><div class=""> }</div><div class=""> if input < 0 { </div><div class=""> return 0 </div><div class=""> }</div><div class=""> input</div><div class="">}</div><div class=""><br class=""></div><div class=""><div class=""><div class="gmail_extra"><br class=""></div><div class="gmail_extra">+1 on omitting return from var {} declaration, those methods look like closures and will often be one-liners.</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sun, Dec 20, 2015 at 5:29 AM, Craig Cruden via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class="">I looked at the discussion and it looked like they were discussion two things combined.<div class=""> - inferred return type (on function signature) </div><div class=""> - and omitting return on the return.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="h5"><div class="">On 2015-12-20, at 4:15:15, Stephen Christopher via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""></div></div><div class=""><div class=""><div class="h5"><div dir="ltr" class="">The discussion I was remembering, comment courtesy of Chris: <div class=""><a href="https://devforums.apple.com/message/1014317#1014317" target="_blank" class="">https://devforums.apple.com/message/1014317#1014317</a><br class=""></div><div class=""><br class=""></div><div class="">(linked from <a href="https://devforums.apple.com/thread/255242" target="_blank" class="">https://devforums.apple.com/thread/255242</a>)</div><div class="gmail_extra"><br class=""></div></div>
</div></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=CGU22LnxbYa2EM3wKvzuC6syQDwKa0tMs5IyT5gL1wJT-2BYD4vVxTNkjz3P-2BxMaTzGkQNfsZYcem-2FDROzdNqEF1b0fZQ3FxI-2FHZ812FCYxRRKvQTmUkEwUfHNDRSEVD6ddMzVM0rm-2B6SuukGhojDCOGi1k6IUbA1sCKZQc1oW1cGHIbzYuZAFeEAMdH2cdqfRhh0vJezQwp83W-2BXaRJf-2FUvAxjmQKHnwfX-2F49MLOng4U-3D" alt="" width="1" height="1" border="0" style="min-height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;" class="">
_______________________________________________<span class=""><br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></span></div></blockquote></div><br class=""></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=1p9Jer2O6jVE9KWvo-2B9iUaEyN8slp4IizyiLwsfp54MbWFefszu7Zz2orCFlOCV6tzT4x0VJt9uf5PHHlBokoQjJ5eXtzqVR5X0UoDf2tpT5NdTK1JiAI5QV1fY9X8Stq3RCFNNkPzBvubogqTfa-2BFy9wJB-2FyWTjgfH-2BAh3fAV9x54I7tjXBLQ6-2FWbF2vsTFznmPandfkPW0J3NiBz4Vy3D4ZNDXX8-2BycWbFJK6cokU-3D" alt="" width="1" height="1" border="0" style="min-height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;" class="">
</div>
<br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div></div></div></div></div>
</div></blockquote></div><br class=""></body></html>