<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 25, 2016, at 10:16 PM, Andrew Trick <<a href="mailto:atrick@apple.com" class="">atrick@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><blockquote type="cite" class="">On Feb 25, 2016, at 4:57 PM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="">I'm concerned about that too, but I think most of these use cases are already impeded by removing tuple argument splatting, since that makes it impossible to make a generic method transformation like `alterMethod<Receiver, Args, Ret>(method: Receiver -> Args -> Ret)`. I think these use cases can be recovered on flattened methods by explicit variadic splatting, since you could then write `alterMethod<Receiver, Args, Ret>(method: (Receiver, Args...) -> Ret)` instead.<br class=""></blockquote><br class="">I don’t really understand that, because the use-cases I’ve seen aren’t in generic context’s<br class=""></blockquote><br class="">Do you have an example in mind of a nongeneric use of curried methods that can't be easily rewritten in terms of a flat method type?<br class=""></blockquote><br class="">I may be off-track, but you mentioned the binary tree example of passing methods as binary closures. Wouldn't the converse be true for wedging state into unary func using existing class methods?<br class=""><br class=""><font face="Menlo" class="">func visit(numbers: [Int], predicate: (Int) -> Bool) {<br class=""> numbers.lazy.filter(predicate).forEach({ print($0) })<br class="">}<br class=""><br class="">// For some reason not a closure...<br class="">class FilterNumbersWithRejects {<br class=""> var rejects = [Int]()<br class=""><br class=""> func check(val: Int) -> Bool {<br class=""> if (val < 100) { return true }<br class=""> rejects.append(val)<br class=""> return false<br class=""> }<br class="">}<br class=""><br class="">let filterNumbers = FilterNumbersWithRejects()<br class="">visit([3, 33, 333], predicate: filterNumbers.check)<br class="">print(filterNumbers.rejects)<br class=""></font></div></div></blockquote><br class=""></div><div>I'm not proposing that we take the ability to use `filterNumbers.check` away. I'm proposing changing the type of the fully unapplied reference FilterNumbersWithRejects.check.</div><div><br class=""></div><div>-Joe</div><br class=""></body></html>