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

[David Owens II]

Thanks for all the initial comments. I have some specific comments about some of the sections in that guideline but I'll hold those until the review. Looking forward to the review!

-David

> On Jan 21, 2016, at 9:56 PM, Chris Lattner <clattner at apple.com> wrote:
> 
> On Jan 21, 2016, at 12:07 PM, David Owens II via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 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.
> 
> The others’ are right, this is best discussed holistically as part of the forthcoming renamification threads.
> 
> That said, the example you picked is exactly illustrative of why the current default works well.  One of the principles of the naming guidelines is “omit needless words”: https://swift.org/documentation/api-design-guidelines.html <https://swift.org/documentation/api-design-guidelines.html> and it is a specific anti-goal of the new naming approach to “simply repeat type information” in an argument name.
> 
> This approach will lead to these APIs actually being imported as:
> 
> 	func register(nib: UINib?, ...
> 	func register(aClass: AnyClass?, …
> 
> These are much better at point of use, and dovetails perfectly with our current keyword argument behavior.
> 
> -Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160121/edb7a0fd/attachment-0001.html>