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

[David Owens II]

> On Jan 21, 2016, at 11:25 AM, Tony Parker <anthony.parker at apple.com> wrote:
> 
> 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.

Interesting. I would have drawn the opposite conclusion. The vast majority of ObjC APIs have the name of the first parameter in the first section of the selector name. This implies, to me, that the name of the first parameter is very important, and because of the syntactical limitation, the name of the action and the name of the first parameter needed to be joined together.

This leads to APIs like this (from UITableView):

func registerNib(_ nib: UINib?, forHeaderFooterViewReuseIdentifier identifier: String)
func registerClass(_ aClass: AnyClass?, forHeaderFooterViewReuseIdentifier identifier: String)

Instead of APIs like:

func register(nib: UINib?, forHeaderFooterViewReuseIdentifier identifier: String)
func register(aClass: AnyClass?, forHeaderFooterViewReuseIdentifier identifier: String)

I don’t think I’m being overly selective in my example, but it seems like overloads make this even more desirable to move the name within the parameter list.


> 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.

I get what you’re saying, we just disagree on the importance of the first parameter’s significance to the function’s purpose. =) I think the primary purpose is “say” and there there is the data for that purpose. Currently, the only data for say is “message:times”, but it’s not hard to see other use cases. I guess my argument is that I think overloads serve that grouping better than different function names that have the same purpose and act on different data. Swift makes it annoying to do that today, so I end up doing neither and just rely on the type system to handle the first parameter difference, which is less than ideal, but it’s the lazy solution.

Thanks for chiming in,
-David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160121/95cf106f/attachment.html>