> * 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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
