[swift-dev] Fixit for trailing closures

[Ben Langmuir]

> On Jul 5, 2016, at 7:57 PM, Erica Sadun via swift-dev <swift-dev at swift.org> wrote:
> 
> 
> 
>> On Jul 5, 2016, at 7:42 PM, Xi Ge via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>> 
>>> 
>>> On Jul 5, 2016, at 5:39 PM, Xi Ge via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>> 
>>>> On Jul 5, 2016, at 5:19 PM, Ben Langmuir <blangmuir at apple.com <mailto:blangmuir at apple.com>> wrote:
>>>> 
>>>>> 
>>>>> On Jul 5, 2016, at 4:34 PM, Xi Ge via swift-dev <swift-dev at swift.org <mailto:swift-dev at 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 at swift.org <mailto:swift-dev at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160706/639eb844/attachment.html>