The review of SE-0013 "Remove Partial Application of Non-Final Super Methods” begins now and runs through January 13th. The proposal is available here:
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
The review of SE-0013 "Remove Partial Application of Non-Final Super Methods” begins now and runs through January 13th. The proposal is available here:
* Is the problem being addressed significant enough to warrant a change to Swift?
It seems like the trade off in functionality is quite minor (and easy to work around with a local closure) and wouldn’t be worth “deep changes” to resolve.
* Does this proposal fit well with the feel and direction of Swift?
Yes, especially as the multiple argument list functionality is going away.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I read through the proposal and the implementation and experimented with a work-around.
-1 from me. We should just go back to the old dispatch mechanism in Swift 2.2, since we're not using the dynamism for anything, and then in Swift 3.0 it's a non-issue, since there are no more curried function declarations and we can handle the other case.
(This is not a very formal review, but my motivation is entirely implementation-based. I did talk to David internally before sending this.)
Since the dynamic dispatch for super methods was already implemented and 2.2 was the active release on master, it seemed natural to propose it for that release at the time. Now that we've already branched for Swift-2.2, I wouldn't be vehemently opposed to not cherry-picking to 2.2.
David
···
On Jan 11, 2016, at 1:53 PM, Jordan Rose <jordan_rose@apple.com> wrote:
-1 from me. We should just go back to the old dispatch mechanism in Swift 2.2, since we're not using the dynamism for anything, and then in Swift 3.0 it's a non-issue, since there are no more curried function declarations and we can handle the other case.
(This is not a very formal review, but my motivation is entirely implementation-based. I did talk to David internally before sending this.)
I think my point is that the 2.2 branch currently contains a broken implementation, so we have to do something there. We don't have to do anything in Swift 3.0, though, because the feature has been removed.
Jordan
···
On Jan 15, 2016, at 10:20, David Farler <dfarler@apple.com> wrote:
Since the dynamic dispatch for super methods was already implemented and 2.2 was the active release on master, it seemed natural to propose it for that release at the time. Now that we've already branched for Swift-2.2, I wouldn't be vehemently opposed to not cherry-picking to 2.2.
David
On Jan 11, 2016, at 1:53 PM, Jordan Rose <jordan_rose@apple.com> wrote:
-1 from me. We should just go back to the old dispatch mechanism in Swift 2.2, since we're not using the dynamism for anything, and then in Swift 3.0 it's a non-issue, since there are no more curried function declarations and we can handle the other case.
(This is not a very formal review, but my motivation is entirely implementation-based. I did talk to David internally before sending this.)
I understand what you meant. Removing the multiple parameter list declarations still isn't in on master, so I will have to throw this new diagnostic until that's in anyway, or just wait for the big syntax change to land. I'm just saying, since these both have to go together as things stand right now, I'm fine with not pushing it for 2.2.
David
···
On Jan 15, 2016, at 10:46 AM, Jordan Rose <jordan_rose@apple.com> wrote:
I think my point is that the 2.2 branch currently contains a broken implementation, so we have to do something there. We don't have to do anything in Swift 3.0, though, because the feature has been removed.
Jordan
On Jan 15, 2016, at 10:20, David Farler <dfarler@apple.com <mailto:dfarler@apple.com>> wrote:
Since the dynamic dispatch for super methods was already implemented and 2.2 was the active release on master, it seemed natural to propose it for that release at the time. Now that we've already branched for Swift-2.2, I wouldn't be vehemently opposed to not cherry-picking to 2.2.
David
On Jan 11, 2016, at 1:53 PM, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:
-1 from me. We should just go back to the old dispatch mechanism in Swift 2.2, since we're not using the dynamism for anything, and then in Swift 3.0 it's a non-issue, since there are no more curried function declarations and we can handle the other case.
(This is not a very formal review, but my motivation is entirely implementation-based. I did talk to David internally before sending this.)