<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 Oct 5, 2016, at 8:15 AM, Jon Akhtar via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;" class="">
<div class="">I agree this seems like a pretty serious oversight. This is very un-swifty. Currying at one time was touted as a language feature, now it is more of an afterthought.</div></div></div></blockquote><div><br class=""></div><div>I see it as a feature that has mostly been removed in Swift 3: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0002-remove-currying.md" class="">SE-0002</a> eliminating the syntax that defined curried functions, and <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md" class="">SE-0042</a> eliminates the production of curried functions when referring to an instance member. I think that’s because, as a language feature, currying wasn’t really carrying it’s conceptual weight: it wasn’t being used *that* often in practice, but—unless you’re already familiar with currying from another language—it’s a fairly complicated notion to understand, and Swift didn’t ever have a complete implementation of currying.</div><div><br class=""></div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;" class="">
<div class=""><br class="">
</div>
<div class="">-Jon</div>
<div class=""><br class="">
</div>
<span id="OLK_SRC_BODY_SECTION" class="">
<div style="font-family: Calibri; font-size: 11pt; text-align: left; border-width: 1pt medium medium; border-style: solid none none; padding: 3pt 0in 0in; border-top-color: rgb(181, 196, 223);" class="">
<span style="font-weight:bold" class="">From: </span><<a href="mailto:swift-evolution-bounces@swift.org" class="">swift-evolution-bounces@swift.org</a>> on behalf of Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>><br class="">
<span style="font-weight:bold" class="">Reply-To: </span>Erica Sadun <<a href="mailto:erica@ericasadun.com" class="">erica@ericasadun.com</a>><br class="">
<span style="font-weight:bold" class="">Date: </span>Tuesday, October 4, 2016 at 09:21<br class="">
<span style="font-weight:bold" class="">To: </span>swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>><br class="">
<span style="font-weight:bold" class="">Subject: </span>[swift-evolution] SE-0111 and Curried argument labels: Unintended Consequences<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
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>
</div>
</span>
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>