[swift-evolution] Xcode Fix-It action for returning closures

[Saagar Jha]

You should probably file a Radar for this, since Xcode isn’t part of the Swift project.

Saagar Jha

> On Jul 13, 2017, at 19:46, iCloud via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi Swift community,
> 
> I was wondering if we have considered adding support for providing Xcode automatic fix-it’s for closures being returned from a function.
> 
> For example, here is an incorrect version of a function that requires two `@escaping` keywords to be inserted.
> 
> func mapping <A, B, C> (f: (A) -> (B)) -> ((C, B) -> (C)) -> ((C, A) -> (C))
> 
> Despite the complexity, the compiler manages to catch two errors.
> 
> 1. Closure use of non-escaping parameter `f` may allow it to escape
>  a. Automatic Fix-it by doing `f: @escaping (A) - > (B)`
> 
> 2. Closure use of non-escaping parameter `reducer` may allow it to escape
>  b. No Fix-it provided <———— 
> 
> As you see above, the two places where a compile-time error occurred had the same exact problem; they both needed a `@escaping`. However, while the function parameter was offered an automatic fix-it, the nested closure being returned was not.
> 
> Here’s the correct version of the function.
> 
> func mapping <A, B, C> (f: @escaping (A) -> (B)) -> (@escaping ((C, B) -> (C))) -> ((C, A) -> (C)) {
>     return { reducer in
>         return { accum, input in
>             reducer(accum, f(input))
>         }
>     }
> }
> 
> I know this is a small feature for a very specific use case but I think it could help make Xcode a little smarter :D 
> Thanks for reading!
> 
> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170713/9b60f4f9/attachment.html>