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

[Matthew Johnson]

> On May 4, 2016, at 1:22 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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.

> 
> 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 at swift.org <mailto:swift-evolution at 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 <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 <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 <https://github.com/apple/swift-evolution/blob/master/process.md>
>> 
>> Thank you,
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> 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/20160504/07f4abaa/attachment.html>