[swift-evolution] named parameters - why hidden first?/proposal interest

[Tony Parker]

Hi David,

This is obviously a topic which gets a lot of discussion, and I doubt I’ll be able to thoroughly convince anyone with an email or two on the topic… but I would like to share one of the reasons behind the decision to avoid labeling the first argument.

We surveyed the entire surface area of the iOS and OS X SDKs, looking to see how many arguments typical methods had. We found that the vast majority of methods actually have just one argument. If we went with a rule that first arguments should be named, then methods like:

sayMessage(“hello”)

would be this instead:

say(message: “hello”)

which isn’t really much of an improvement, in my mind.

Furthermore, when methods have more than one argument, we found that the additional arguments are most often modifiers or minor adjustments to the first argument. Or, put another way: when there are multiple arguments, the first argument is almost always far more important to the meaning of the method. Your example below follows this pattern as well: the primary purpose of the function is to say a message. The number of times it is said is a secondary modifier to the central purpose.

These factors led us to the conclusion that the label of the first argument is (in the vast majority of cases) really part of the method and not equal in importance to the remaining labels.

- Tony


> On Jan 21, 2016, at 9:23 AM, David Owens II via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Ok, this is something that's bugged me since Swift was released. It was almost fixed it back in the 1.x days (I think that was when it changed to be a bit more consistent between top-level funcs and members funcs).
> 
> The question is this, why do we still implicitly have unnamed first parameters for non-init functions, and in some cases, suggest putting the name of the first parameter in the name of the function? 
> 
>     func say(message: String, times: Int) { ... } // or
>     func sayMessage(message: String, times: Int) { ... }
> 
>     say("hello world", times: 5) // or
>     sayMessage("hello world", times: 5)
> 
>     // vs.
> 
>     say(message: "hello world", times: 5)
> 
> Let me be clear, I completely understand why the _ is supported, and I understand that it's not feasible to implicitly convert all the ObjC interfaces to move the parameter name into the first position (though they could be annotated to do this...).
> 
> However, why are we continuing that tradition with _new_ Swift APIs? There seems to be a perfectly good spot for the first parameter name of a function: the first parameter slot.
> 
> The seemingly poor choice of this shows up in other places too, like Doug Gregor's Naming Functions with Arguments Labels proposal. The default for that is to always have the _ in the first name slot.
> 
>     say(_:times:)
>     sayMessage(_:times:)
> 
>     // vs.
> 
>     say(message:times:)
> 
> The other unfortunate thing about this, is that this is another instance where "init" behaves differently then the rest of Swift. I think it would be great to unify this.
> 
> Am I just missing the really compelling rationale for this?
> 
> Thanks,
> David
> _______________________________________________
> 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/20160121/24394f7c/attachment.html>