[swift-dev] Fixit for trailing closures

[Xi Ge]

> On Jul 5, 2016, at 5:39 PM, Xi Ge via swift-dev <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.
>>> 
>>> Fixits can enhance the discoverability of trailing closures by identifying misuses and by transforming users’ code automatically. However, adding the fixit introduces new issues:
>>> 
>>> Issue 1: The fixit has to be associated with a warning. Adding the warning means we declare wars against convertible non-trailing closures, which is a valid syntax choice by users.
>>> 
>>> Issue 2: Ambiguity checking should be exhaustive. We have several known situations when non-trailing closures cannot be convert to trailing closures, including:
>>> 	
>>> Trailing closures are followed by other brackets, e.g., “if foo({}) {}” cannot be converted to “if foo {} {}”.
>>> Removing the label of the last closure causes ambiguous function references, e.g. “foo(v: {})” cannot be converted to “foo {}” when “foo(v1: {})” also exists.
>>> 
>>> So Swift-devs, is the warning worth adding? If yes, are there other situations of ambiguity that are not covered?
>>> 
>>> Thanks for your feedback!
>>> Xi
>>> 
>> 
>> -1, this feels like a really good tool to have in a code-linter, but not something that we should put in the compiler and prescribe to all our users.
>> 
>> My biggest concern is that it’s not always obvious what the closure is used for.  The argument label can help with this:
>> 
>> [1].lexicographicallyPrecedes([0]) { <#code#> }
>> [1].lexicographicallyPrecedes([0], isOrderedBefore: { <#code#> })
>> 
> 
> oh, good example! The code examples I came up with are those where labels are not very informative, like:
> 
>   q.async(execute: {})
>   q.after(when: DispatchTime.now(), execute: {})
> 
> Probably, the warning/fixit should be opt-out/in, like an attribute @trailing_closure_prefered on the function decl, thoughts?
> 
> 

Another benefit of adding such attribute is to govern code completion UI the way to expand a closure placeholder. Currently, we expand
closure unequivocally to trailing closures, even for lexicographicallyPrecedes(isOrderedBefore:)


>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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>
> _______________________________________________
> 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/20160705/b50b34e4/attachment.html>