<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I do not think the boat has sailed. I do remember this issue being actually revisited after initial approval because of the impact it had and quite a few members in this list, myself included, thought it was not helping readability and clarity and that it was strange this came after putting so much emphasis on argument labels for methods... and rightfully so.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">From what I remember Chris L. said the actual state of things is not how the final solution of the problem will look like, but that for Swift 3.0 they needed to simplify how argument labels were treated as part of the type system and short term needs won, but that the team agreed that the solution had to be revisited and solved. I will try to look for that message.<br><br>Sent from my iPhone</div><div><br>On 4 Oct 2016, at 17:21, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=us-ascii">SE-0111 established that Swift's type system would not allow function argument labels to be expressed as part of a function type. As I've been working with curried functions, I'm discovering an unintended consequence of this proposal in that it strips curried functions of their external labels and the resulting calls of their readability.<div class=""><br class=""></div><div class="">```</div><div class=""><div class=""><font face="Menlo" class="">public func projected(</font></div><div class=""><font face="Menlo" class=""> function f: @escaping (CGFloat) -> CGFloat) -></font></div><div class=""><font face="Menlo" class=""> (_ p0: CGPoint, _ p1: CGPoint) -> </font></div><div class=""><font face="Menlo" class=""> (_ percent: CGFloat) -> CGPoint</font></div><div class=""><font face="Menlo" class="">{</font></div></div><div class="">```</div><div class=""><br class=""></div><div class="">Calling the first level of currying still reads acceptably:</div><div class=""><br class=""></div><div class="">```</div><div class=""><font face="Menlo" class="">let projectedFunction = projected(function: fToApply)</font></div><div class="">```</div><div class=""><br class=""></div><div class="">But after that, the enforced label-less arguments mean all further semantics have to stay within the name of the assigned partially applied function symbol and all arguments must be supplied without meaning, which is not in the spirit of API guidelines or under the umbrella of Swiftiness:</div><div class=""><br class=""></div><div class="">```</div><div class=""><font face="Menlo" class="">let fixedFunction = projectedFunction(p0, p1)</font></div><div class=""><font face="Menlo" class="">let value = fixedFunction(0.2)</font></div><div class="">```</div><div class=""><br class=""></div><div class="">There's no way to give either the line segment start and end points or the percent-of-progress arguments any labels. Further, Xcode/QuickHelp does not provide any support for documenting the roles of each curried return type.</div><div class=""><br class=""></div><div class="">Could this be addressed specifically for currying or has the boat sailed forever on this topic?</div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>