> On 7 Oct 2017, at 19:22, Tony Allevato via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> I think the important thing to consider is, what advantage would such a
> feature provide *other* than to reduce keystrokes? (I don't personally think
> that optimizing for keys pressed by itself should be a goal.)
>
> In the case of closures, single expression closures without "return" improve
> readability because such closures are often chained for functional
> programming patterns:
>
> someArray.filter { $0.isFloopy }.map { $0.grobber }
>
> Having "return" there would be noise that detracts from understanding what's
> going on in that algorithm. It's also worth noting that in this context, the
> closure *itself* is also an expression.
>
> In functions, property getters, and subscripts, the same constraints don't
> really hold. They're declarations, not expressions, so they don't chain
> together and they're not subject to the same readability problems as closure
> expressions.
Agreed. I would be wary because consistency would push us to allow it in
functions also and I’m not sure it makes as much sense there.
>> On Sat, Oct 7, 2017 at 9:59 AM Nevin Brackett-Rozinsky via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>> On Sat, Oct 7, 2017 at 11:24 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>> This has been brought up on the list before. For instance:
>>>
>>> https://github.com/apple/swift-evolution/pull/608
>>>
>>> Chris Lattner’s response at that time was:
>>>
>>> ‘Just MHO, but I consider this syntactic sugar, not a fundamental feature
>>> that fits the goal of Swift 4 stage 2.
>>>
>>> ‘I’m also pretty opposed to doing it at any time. The rationale of
>>> “implicit return” in closures is specifically because they are limited to a
>>> single expression, which makes the semantics “obvious”. This was carefully
>>> considered.’
>>
>> This objection is not applicable, because we are discussing the possibility
>> to omit “return” exactly when there is a single expression in the getter.
>>
>> Nevin
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
