[swift-evolution] Swift 2.2: Removing partial application of super method calls

[Slava Pestov]

> On Dec 10, 2015, at 10:57 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Dec 10, 2015, at 10:38 PM, David Farler <dfarler at apple.com <mailto:dfarler at apple.com>> wrote:
>> 
>>> 
>>> " 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.”
>>> 
>>> 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:
>>> 
>>> class Foo {
>>>   func bar() {}
>>> }
>>> 
>>> let fn = Foo.bar
>>> fn()
>> 
>> Yes, that's what I had meant actually but the wording was probably too broad. 
>> 
>>> 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.
>>> 
>>> -Chris
>> 
>> 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?
> 
> 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 :-)

I was thinking one potential use of partially-applied super is something like the following:

class Base {
	func doSomething() {}
	func doSomethingElse() {}
}

class Derived : Base {
	func executeAwesomely(f: () -> ()) { … f() … }

	override func doSomething() {
		executeAwesomely(super.doSomething)
	}

	override func doSomethingElse() {
		executeAwesomely(super.doSomethingElse)
	}
}

I’ve written similar things before in Factor but I’m not sure if that counts as a real use-case :-)

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.

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.

Slava


> 
> -Chris
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151211/e99cdde0/attachment.html>