> On Jul 5, 2016, at 7:57 PM, Erica Sadun via swift-dev <swift-dev@swift.org>
> wrote:
>
>
>
>> On Jul 5, 2016, at 7:42 PM, Xi Ge via swift-dev <swift-dev@swift.org
>> <mailto:swift-dev@swift.org>> wrote:
>>
>>>
>>> On Jul 5, 2016, at 5:39 PM, Xi Ge via swift-dev <swift-dev@swift.org
>>> <mailto:swift-dev@swift.org>> wrote:
>>>
>>>> On Jul 5, 2016, at 5:19 PM, Ben Langmuir <blangm...@apple.com
>>>> <mailto:blangm...@apple.com>> wrote:
>>>>
>>>>>
>>>>> On Jul 5, 2016, at 4:34 PM, Xi Ge via swift-dev <swift-dev@swift.org
>>>>> <mailto:swift-dev@swift.org>> wrote:
>>>>>
>>>>> Hi Swift-devs,
>>>>> I have tried to add a fixit to help developers using trailing closures
>>>>> more, motivated by my observation during WWDC that some developers
>>>>> do not even realize that we have such a feature. In my opinion, trailing
>>>>> closures are more concise, and once you get used to it, more readable;
>>>>> therefore users should adopt trailing closures whenever doing so
>>>>> introduces no ambiguity.
>
>
> I prefer trailing closures for -> Void signatures and in-line closures for
> anything (notably sequences and collections) that is likely to be iterated
> through or chained functionally.
I’m not sure if this matches your personal preferences, but your example made
me realize the decision can also easily be context-dependent. I would probably
write a single map with a trailing closure,
[0, 1, 2, 3].map {
// code
}
But a chain without trailing closures.
[0, 1, 2, 3].map({ /* code */ }).filter({ /* code */})
> I also prefer inline closures for items that have multiple states for
> callback (completion handlers, error handlers, etc, where there is going to
> be a test of some kind -- we don't have a Result type but if we did, it would
> fall here -- and contains error/value pairs) and trailing closures for
> no-state-will-execute such as GCD.
And these callbacks are a place I really like to use trailing closures, which
reinforces to me that we shouldn’t try to force one style or the other.
>
> -- E
>
> _______________________________________________
> swift-dev mailing list
> swift-dev@swift.org <mailto:swift-dev@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-dev
> <https://lists.swift.org/mailman/listinfo/swift-dev>
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
