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

Chris Lattner clattner at apple.com
Fri Dec 11 00:57:29 CST 2015

> On Dec 10, 2015, at 10:38 PM, David Farler <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 :-)

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

More information about the swift-evolution mailing list