This has been reported as SR-5556 <https://bugs.swift.org/browse/SR-5556>. In the future, please report bugs like this through bugs.swift.org <http://bugs.swift.org/> and/or Radar.
Thanks, ~Robert Widmann > On Jul 13, 2017, at 7:46 PM, iCloud via swift-evolution > <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
