[Review] SE-0060: Enforcing order of defaulted parameters


(Chris Lattner) #1

Hello Swift community,

The review of "SE-0060: Enforcing order of defaulted parameters" begins now and runs through May 9. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0060-defaulted-parameter-order.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 contribute to 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 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,

-Chris Lattner
Review Manager


(Charles Srstka) #2

Count me among those who had no idea this feature even existed.

The thing about the current behavior that strikes me as odd is that it only applies to parameters with default values. So foo(a: Int = 1, b: Int = 2) is reorderable, whereas foo(a: Int, b: Int) is not. This seems fairly inconsistent and quite weird, given that both forms contain the same amount of information that would be pertinent to determining order. So the behavior should probably change one way or the other; either remove it entirely, or extend it to labeled parameters without defaults.

Charles

···

On May 3, 2016, at 10:52 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0060: Enforcing order of defaulted parameters" begins now and runs through May 9. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0060-defaulted-parameter-order.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 contribute to 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 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,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #3

  * What is your evaluation of the proposal?

I am unsure. I am definitely not fully convinced yet.

I believe a change like this deserves more analysis of the impact of reordering on call site clarity when used with existing APIs. If the argument labels of defaulted parameters in most current APIs usually form part of an english-like phrase continuing from the non-defaulted arguments I would generally be in support of this proposal. Allowing reordering with such APIs would be confusing and negatively impact call site clarity.

However, my hunch is that in many cases they are more like “options” where order is somewhat arbitrary (maybe most frequently used come first) and where reordering would not have a significant impact on the readability or clarity at the call site. If this is the case one could argue that requiring callers to know the correct order for the “options” is an unnecessary cognitive burden. The benefit of consistency may still outweigh that burden but I am not sure it would. I believe a stronger argument would need to be made as to specifically *how* this change benefits users in order to offset the burden or requiring callers to remember the specific order of “options” arguments.

If analysis of existing APIs shows that defaulted parameters generally fall into the “options” pattern where call site clarity is not negatively impacted by reordering I would be opposed to this proposal. This is a pattern I have found quite useful in other languages. It would be a little bit sad and annoying to be required to remember the correct order for such arguments in Swift, especially when this has not been necessary thus far. This pattern is much more useful in some domains than others, but its usefulness is widespread enough that it deserves more consideration than it has been given.

To summarize, with a more complete analysis we may find that the current design strikes a useful balance: required parameters may typically form a “phrase” where strict ordering is essential to clarity, while defaulted arguments may typically be “options” that can be reordered freely without a negative impact to call site clarity and with the benefit that we don’t need to memorize the correct order for “options” arguments.

I hope we don’t rush this through without analysis of current APIs just because it is a breaking change that must happen in Swift 3 or not happen at all.

As noted under alternatives, I do think allowing reordering makes sense for memberwise initialization, however in that case *all* memberwise arguments should be reorderable, not just defaulted arguments. As this use case isn’t well supported by the current feature anyway it isn’t a huge loss. Memberwise initialization is very likely to be improved eventually, quite possibly in Swift 4 (Chris is a big proponent of doing something here). Assuming that happens, there will be ample opportunity to consider reordering for that use case as a part of that proposal.

  * Is the problem being addressed significant enough to warrant a change to Swift?

Possibly.

  * Does this proposal fit well with the feel and direction of Swift?

Yes in the sense that it is revisiting early design decisions and seeking to improve consistency with the changes to the direction of the language that have happened subsequently.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I have used several languages that allow for arbitrary ordering of “options” arguments in one way or another. I have generally found it quite useful to not need to be concerned with providing such arguments in a specific order.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I have given this a fair bit of consideration.

···

More information about the Swift evolution process is available at

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

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #4

Here is a real world example of where I use defaulted parameters:

public extension UIView {

public convenience init(

    _ w: CGFloat,

    _ h: CGFloat,

    position: CGPoint = .zero,

    backgroundColor: UIColor = UIColor.whiteColor(),

    translucency alpha: CGFloat = 1.0,

    borderWidth: CGFloat = 0.0,

    borderColor: UIColor = UIColor.blackColor(),

    cornerRadius: CGFloat = 0.0

    ){

    self.init(frame: CGRect(x: position.x, y: position.y, width: w, height: h))

    self.backgroundColor = backgroundColor.colorWithAlphaComponent(alpha)

    self.layer.borderWidth = borderWidth

    self.layer.borderColor = borderColor.CGColor

    self.layer.cornerRadius = cornerRadius

    self.translatesAutoresizingMaskIntoConstraints = false

}

}

It’s not a beautiful initializer or aspirational code. It is convenient for putting together flexible views in playgrounds. This utility controls the axes I typically want to tweak for view creation:

  • How big is it (w, h)

  • Where is it? (position, if used, for example, as a subview)

  • What color is it? Is the color solid or translucent? (backgroundColor, translucency)

  • Does it have a border? and if so, how wide and what color? (borderWidth, borderColor)

  • Are the corners rounded and to what degree? (cornerRadius)

The reason I present this example is that while there are relationships between some of the defaulted values, there is absolutely no inherent order to those groups. When putting together a view, I may later decide to add, for example, the border. Should I have to know that the border must appear before any background color settings?

Having to figure out where a previously defaulted value should be inserted when adding an explicit setting imposes an undue burden on the programmer, reduces flexibility during experimentation, and removes one of the neatest Swift features. For this reason, I vote no on the proposal. By rejecting this proposal, Swift retains a flexibility that defers to the programmer, placing the programmer’s needs before any benefits that may accrue to the compiler.

I have followed the discussion. I believe it goes against the general Swift philosophy. And while the change being proposed is significant to be part of a formal language review process, I think adopting it would be the wrong thing to do.

– Erica

···

On May 3, 2016, at 9:52 PM, Chris Lattner via swift-evolution swift-evolution@swift.org wrote:

Hello Swift community,

The review of “SE-0060: Enforcing order of defaulted parameters” begins now and runs through May 9. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0060-defaulted-parameter-order.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 contribute to 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 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,

-Chris Lattner
Review Manager


swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Michael Peternell) #5

comments inline

Hello Swift community,

The review of "SE-0060: Enforcing order of defaulted parameters" begins now and runs through May 9. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0060-defaulted-parameter-order.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 contribute to 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?

+1 The advantage is that the code becomes easier to understand if everyone uses the same parameter order. The disadvantage is that users don't have as much freedom to re-order the parameters as they like. I think the advantage weighs more. Furthermore, having different parameter orders in the same program could probably give the impression that the parameter order is important. If only one parameter order is possible, there can be no confusion regarding that.

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

  * Does this proposal fit well with the feel and direction of Swift?

Yes.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Haven't used.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the proposal, imagined some friends discussing how the parameters should be ordered for a particular function, and thought "let's remove this trap from the language."

-Michael

···

Am 04.05.2016 um 05:52 schrieb Chris Lattner via swift-evolution <swift-evolution@swift.org>:


(Matthew Johnson) #6

Here is a real world example of where I use defaulted parameters:

public extension UIView {
    public convenience init(
        _ w: CGFloat,
        _ h: CGFloat,
        position: CGPoint = .zero,
        backgroundColor: UIColor = UIColor.whiteColor(),
        translucency alpha: CGFloat = 1.0,
        borderWidth: CGFloat = 0.0,
        borderColor: UIColor = UIColor.blackColor(),
        cornerRadius: CGFloat = 0.0
        ){
        self.init(frame: CGRect(x: position.x, y: position.y, width: w, height: h))
        self.backgroundColor = backgroundColor.colorWithAlphaComponent(alpha)
        self.layer.borderWidth = borderWidth
        self.layer.borderColor = borderColor.CGColor
        self.layer.cornerRadius = cornerRadius
        self.translatesAutoresizingMaskIntoConstraints = false
    }
}

It's not a beautiful initializer or aspirational code. It is convenient for putting together flexible views in playgrounds. This utility controls the axes I typically want to tweak for view creation:

* How big is it (w, h)
* Where is it? (position, if used, for example, as a subview)
* What color is it? Is the color solid or translucent? (backgroundColor, translucency)
* Does it have a border? and if so, how wide and what color? (borderWidth, borderColor)
* Are the corners rounded and to what degree? (cornerRadius)

The reason I present this example is that while there are relationships between some of the defaulted values, there is absolutely no inherent order to those groups. When putting together a view, I may later decide to add, for example, the border. Should I have to know that the border must appear before any background color settings?

Having to figure out where a previously defaulted value should be inserted when adding an explicit setting imposes an undue burden on the programmer, reduces flexibility during experimentation, and removes one of the neatest Swift features. For this reason, I vote no on the proposal. By rejecting this proposal, Swift retains a flexibility that defers to the programmer, placing the programmer's needs before any benefits that may accrue to the compiler.

Thanks for bringing a concrete example to the discussion Erica. This is a good example of the memberwise initializer use case for reordering. This is exactly the kind of cognitive burden I mentioned in my review. This burden is also present for *any* function which might have “options” with defaults, it does not just apply to initializers.

I’m really glad you discussed code evolution as I was only thinking about writing new code and reading code when considering this proposal. I think you have swayed me firmly into the -1 camp unless it can be demonstrated that there are many existing APIs which are negatively impacted at the call site by reordering of their defaulted arguments. Adding and removing “options” from a call to an initializer or function such as this is not an uncommon thing to do (at least in some domains such as apps), and as you point out facilitating experimentation is a big part of what Swift is about.

IMO this example also demonstrates why it may also be desirable to also allow reordering of “w” and “h” as there really is no inherent order present in those either and enforcing an order does not add clarity in this case. That said, the case for enforcing order here is stronger than the one for defaulted arguments, partly because they always *must* be present and are therefore not as subject to the “experimentation” burden you describe.

···

On May 4, 2016, at 1:22 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

I have followed the discussion. I believe it goes against the general Swift philosophy. And while the change being proposed is significant to be part of a formal language review process, I think adopting it would be the wrong thing to do.

-- Erica

On May 3, 2016, at 9:52 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello Swift community,

The review of "SE-0060: Enforcing order of defaulted parameters" begins now and runs through May 9. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0060-defaulted-parameter-order.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 contribute to 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 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,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Dave Abrahams) #7

FWIW, Erica echoes my instincts on the topic.

···

on Wed May 04 2016, Erica Sadun <swift-evolution@swift.org> wrote:

Having to figure out where a previously defaulted value should be inserted when
adding an explicit setting imposes an undue burden on the programmer, reduces
flexibility during experimentation, and removes one of the neatest Swift
features. For this reason, I vote no on the proposal. By rejecting this
proposal, Swift retains a flexibility that defers to the programmer, placing the
programmer's needs before any benefits that may accrue to the compiler.

I have followed the discussion. I believe it goes against the general Swift
philosophy. And while the change being proposed is significant to be part of a
formal language review process, I think adopting it would be the wrong thing to
do.

-- Erica

--
Dave