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

[Joe Groff]

> On Jan 21, 2016, at 1:58 PM, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Jan 21, 2016, at 12:33 PM, Charles Constant via swift-evolution <swift-evolution at swift.org> wrote:
>>> say("hello")
>>> 
>>> is a big improvement, which IMO perfectly illustrates why we want the
>>> default as it is.
>> 
>> Maybe so, but there just has to be some way to do this that doesn't bake the design into the entirety of the Swift language. Is there some way Apple could implement this that only affects Swift imports/exports with Obj-C?
> 
> You’re repeating your assumption here that the current design was reached by necessity for ObjC importing.  That is not the case.  As has been said multiple times in this very thread, we looked at a lot of existing APIs — and of course those APIs included ObjC APIs, but not exclusively by any stretch — and decided that, far more often than not, the first argument of a function/method is a “direct object” whose relationship to the operation is obvious and does not benefit from labelling.  We strongly considered adopting the rule that all arguments should be labelled by default, and we decided that, on balance, it led to a lot of really useless labels.  It’s a very simple and understandable language rule, but it leads to worse results when you actually apply to it to real code.  There are, of course, exceptions, but there would have been in any case.
> 
> But like Dave said, we’re about to have a major conversation about this, and you are welcome to participate.

One thing to consider is, if you follow either Cocoa's contemporary naming conventions or the proposed Swift 3 naming conventions, then the labels you end up with for secondary arguments frequently aren't good binding names, so the conventions steer you toward providing an explicit binding name:

// Classic Cocoa style
func doStuff(stuff: Stuff, involvingThing thing: Thing) { ... }
// Swift 3 style
func do(stuff: Stuff, involving thing: Thing) { ... }

We could make the language rules more consistent, while still encouraging people to follow the naming guidelines, by *requiring* every argument after the first to specify both an argument label (or explicit '_') and binding name. That makes the naive 'min(x: Int, y: Int)' case an error we can provide an easy fixit for.

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