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