As another member of the “anti-fan-club” for the unnamed first parameter, I have to ask: what would be wrong with:
- single-argument functions: default to unnamed “first” (really: only) parameter
- multi-argument functions: default to all-named parameters
…(other than the obvious inconsistencies/special-casing so introduced)?
I mean more in terms of design goals/readability concerns.
The API guidelines seem to address two scenarios for multi-argument functions:
- functions in which one argument is the "semantic focus” (and thus deserves to be the first argument, with its description folded-into the method name)
- functions in which all arguments are “co-equal participants” and have *identical* semantic roles, in which case all parameters should go un-named (e.g. ==, zip, etc.)
…but don’t address a third scenario, wherein:
- there are multiple arguments
- no one argument is the obvious, natural “semantic focus” of the method (thus there’s no natural candidate for which argument’s label ought to get folded-into the method name)
- the arguments all have distinct logical-roles within the method (thus the all-unnamed approach is not great)
…which scenario I think is not all that uncommon in application code (anecdotally 15-30%, depending on problem domain)?
As an example, consider something like this:
protocol PresentationController {
typealias Content
typealias PresentationUpdate
// one of these feels right:
func inferPresentationUpdate(fromPrevious previous: Content, toCurrent current: Content) -> PresentationUpdate
func inferPresentationUpdate(from previous: Content, to current: Content) -> PresentationUpdate
// none of these feels right:
func inferPresentationUpdateFrom(content: Content, toCurrent current: Content) -> PresentationUpdate
func inferPresentationUpdateFrom(content: Content, to current: Content) -> PresentationUpdate
func inferPresentationUpdateFromPrevious(content: Content, toCurrent current: Content) -> PresentationUpdate
func inferPresentationUpdateFromPrevious(content: Content, toCurrent current: Content) -> PresentationUpdate
// nor do any of these:
func inferPresentationUpdateTo(content: Content, fromPrevious previous: Content) -> PresentationUpdate
func inferPresentationUpdateTo(content: Content, from previous: Content) -> PresentationUpdate
func inferPresentationUpdateToCurrent(content: Content, fromPrevious previous: Content) -> PresentationUpdate
func inferPresentationUpdateToCurrent(content: Content, from previous: Content) -> PresentationUpdate
}
…which is as always a bit contrived, but illustrates a scenario wherein neither parameter is arguably the natural "semantic focus” of the method.
(If you need to be convinced this shouldn’t be a method on `Content`, consider that `Content` may be a simple model entity, and that different types of “presentations” may differ in how they want to present model *updates* to the user).
But that’s my 2c; I don’t like the inconsistency, I understand the stated reasons for it, but I think multi-argument methods w/out an obvious “semantic focus” are common enough to deserve consideration.
···
On Jan 24, 2016, at 6:32 AM, Charles Constant via swift-evolution <swift-evolution@swift.org> wrote:
> With our current Objective-C style, we need to repeat at least one word and often need to include "with", "by", "using", etc. to make it read nicely
When it comes to my own code, I agree with you 100%. However, if I understand the Swift team's rationale, using a label for the first argument is more often than not, bad form.
The point I was trying to make with the pros/cons bullet points is that, even being charitable with the cons and understated about the pros, the change still makes more sense.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution