Also since the example rewrite is a single line function it could be rewritten
as:
def f2(input: Integer) : Integer = input match {
case _ if input > 10 => 10
case _ if input < 0 => 0
case _ => input
}
Even with the overkill of pattern matching it — it still is easy to understand
what is being returned without forcing the use of “return” all over the place.
> On 2015-12-20, at 22:30:28, Craig Cruden <[email protected]> wrote:
>
> 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]
>> <mailto:[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
