> On Jul 5, 2016, at 5:39 PM, Xi Ge via swift-dev <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. >>> >>> 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@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 <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
