<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 Dec 10, 2015, at 10:57 PM, Chris Lattner 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=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 10, 2015, at 10:38 PM, David Farler <<a href="mailto:dfarler@apple.com" class="">dfarler@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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;" class=""><div class=""><div class=""><div class=""><br class="Apple-interchange-newline">" Currying will be removed in Swift 3.0 so, rather than invest more engineering in those mechanisms, I propose that we disallow partial application of non-final methods through super, except where the self parameter is implicitly captured.”</div><div class=""><br class=""></div><div class="">This isn’t true. The proposal you’re referring to removes the “func f(a : Int)(b : Int)” syntax, but methods will still be curried. It will still be perfectly legal to do:</div><div class=""><br class=""></div><div class="">class Foo {</div><div class=""> func bar() {}</div><div class="">}</div><div class=""><br class=""></div><div class="">let fn = Foo.bar</div><div class="">fn()</div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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;" class=""><br class=""></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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; float: none; display: inline !important;" class="">Yes, that's what I had meant actually but the wording was probably too broad. </span><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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;" class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="">So, I think that in a perfect world, the implementation would lazily generate curry thunks for super partial applications, and we would keep the current behavior. However, if it is a significant implementation burden, I’d support doing a survey of existing code to see how widely used this is. I suspect it is rare, and if you can prove this, we may be able to knowingly break compatibility in this case in the service of getting the ABI stability.</div><div class=""><br class=""></div><div class="">-Chris</div></div></div></blockquote><div class=""><br class=""></div><div class="">It's probably not too burdensome in an absolute sense but it is more effort to thread the right information through a mechanism that expects arbitrary levels of currying. I figured it might be better to plug it into a (potentially) simpler system after we would only expect certain uncurry levels. Maybe that's not a good bet, though! Things are working as they are now but I can really make either work. What do you think?</div></div></div></blockquote><br class=""></div><div class="">I’d suggesting that Joe Groff chime in on this, but my sense is that if there is no overwhelming implementation concern, that we’d prefer to keep currying of super methods. It’s a totally narrow feature, but since we already support it, it would be nice to not regress. Curry all the things :-)</div></div></div></blockquote><div><br class=""></div></div><div>I was thinking one potential use of partially-applied super is something like the following:</div><div><br class=""></div><div>class Base {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>func doSomething() {}</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>func doSomethingElse() {}</div><div>}</div><div><br class=""></div><div>class Derived : Base {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>func executeAwesomely(f: () -> ()) { … f() … }</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>override func doSomething() {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>executeAwesomely(super.doSomething)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>override func doSomethingElse() {</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>executeAwesomely(super.doSomethingElse)</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>}</div><div>}</div><div><br class=""></div><div>I’ve written similar things before in Factor but I’m not sure if that counts as a real use-case :-)</div><div><br class=""></div><div>As David mentioned the curry thunk code is rather complex and duplicates a lot of policy that’s encoded in SILGenApply.cpp. Now that @objc protocol methods can be partially applied, I think the main missing feature here is ‘Proto.someInstanceMethod’ unbound protocol method references. There might be some other corner cases too (dynamic method references perhaps?) It does feel like each corner case adds a sprinkle of ‘if’ statements in random places throughout the code.</div><div><br class=""></div><div>How about we keep super.foo around for now. Once we get around to adding all the missing corner cases, we can try to re-organize and simplify the curry thunks implementation, and maybe then decide if we want to drop anything that it does.</div><div><br class=""></div><div>Slava</div><div><br class=""></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;" class=""><div class=""><br class=""></div><div class="">-Chris</div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=NLTid1W7V2mxBEfr5Y3KfTntaxSmOQp5vjACZc9Eh1-2B4Qxis5thBAd69WnlG6vwH5dYD6VGebCJ2waHLfhYo43YOY1ZfUSCSmTq3HX8TcUdLFhCRVH9uNTocjfoInEfcvV6C-2B7QdIOrjGcsrhJuUVTRhj1bXgaN5VL1v-2Bd12xlMlwHeQdLgUJdm31YkiL3Qbq-2Fd2ydxNh6SJKI-2FViG7nksh-2Bi5cif9LmtKtqItnLLQI-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</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>