<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Here's a draft of the proposal:<div class=""><br class=""></div><div class=""><a href="https://github.com/bitjammer/swift-evolution/blob/remove-partial-super/proposals/0008-remove-partial-application-super.md" class="">https://github.com/bitjammer/swift-evolution/blob/remove-partial-super/proposals/0008-remove-partial-application-super.md</a></div><div class=""><br class=""></div><div class="">David</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 7, 2015, at 3:37 PM, David Farler <<a href="mailto:dfarler@apple.com" class="">dfarler@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">I'd like to add that this would only apply to super invocation of non-final methods. Final methods always terminate with a static function reference, so the existing curry thunk mechanisms will continue to work with those until we remove them.<br class=""><br class="">David<br class=""><br class=""><blockquote type="cite" class="">On Dec 7, 2015, at 1:51 PM, David Farler <<a href="mailto:dfarler@apple.com" class="">dfarler@apple.com</a>> wrote:<br class=""><br class="">Hi all,<br class=""><br class="">I'd like to propose removing partial application of super method calls (except bare `super.foo` which implicitly captures `self`) in Swift 2.2.<br class=""><br class="">This is motivated by the upcoming removal of curried function declaration syntax in Swift 3 combined with making super method calls dynamically dispatched instead of statically dispatched as they are now, which is scheduled to land in Swift 2.2.<br class=""><br class="">The reason why dynamic dispatch is a motivator is mostly driven by implementation details, specifically how we emit partial application thunks. These thunks ultimately result in a static function reference, which is called immediately, or a dynamic dispatch through a class method. Now, you might be wondering how class methods differ from dynamic dispatch via super methods. Class methods use dynamic dispatch through the instance pointer to the class metadata for the vtable lookup, whereas super method dynamic dispatch loads the statically known superclass's metadata instead.<br class=""><br class="">The logic around curry thunk emission is rather complicated so I'd like to go ahead and make partial applications based in `super` disallowed, rather than invest time in an area we'll be ripping up in Swift 3 and increase risk for regressions in Swift 2.2.<br class=""><br class="">The implementation for disallowing this is dead simple and I've already got a patch for that. I should also mention that I can't safely turn on the new dynamic super method dispatch mechanics in Swift 2.2 until we address this one way or the other. I do have progress on emitting curry thunks for these kinds of partial applications but it is a rather large patch that I'd like to avoid for Swift 2.2 if possible.<br class=""><br class="">David<br class=""></blockquote><br class=""></div></div></blockquote></div><br class=""></div></body></html>