[Review] SE-0013 Remove Partial Application of Non-Final Super Methods


(Douglas Gregor) #1

Hello Swift community,

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:

  https://github.com/apple/swift-evolution/blob/master/proposals/0013-remove-partial-application-super.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

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

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,
Doug Gregor
Review Manager


(Jesse Rusak) #2

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:

  https://github.com/apple/swift-evolution/blob/master/proposals/0013-remove-partial-application-super.md

  * What is your evaluation of the proposal?

This seems very reasonable to me.

  * 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.

- Jesse


(Jordan Rose) #3

-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.)

Jordan


(David Farler) #4

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.)

Jordan


(Jordan Rose) #5

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.)

Jordan


(David Farler) #6

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.)

Jordan