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

[Jessy Catterwaul]

Excuse me if this has been mentioned already. I just subscribed to this list and don’t know anything about how to use it.

It seems to me that there is a third choice for parameter names, which has yet to be explored. The way protocols are implemented now can educate us about it:

protocol Protocol {
   // This argument label does nothing, 
   // but is required for compilation.
   func function(int: Int)
}

// This compiles.
struct Struct: Protocol {
   func function(not_int_atAll: Int) {}
}

Because internal parameter names in protocol names do nothing, they should not be required:
protocol Protocol {
   func function(Int)
}

This inspires the following syntax:
struct Struct: Protocol {
   func function(Int) {
      // The parameter is called $0 here
   }
}

This kind of thing is sorely needed for operators, which use the standards “lhs” and “rhs” despite no hands being involved.

struct Struct: Protocol {
   // Should also be valid;
   // but we should explicitly have to 
   // opt out of external naming.
   func function(_ int: Int) {}
}
struct Struct: Protocol {
   // Should not be valid;
   // int is now the external parameter name
   func function(int: Int) {}
}
struct Struct: Protocol {
   // Should not be valid.
   func function(preposition int: Int) {}
} 


> On Jan 21, 2016, at 5:04 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Jan 21, 2016, at 1:58 PM, John McCall via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> On Jan 21, 2016, at 12:33 PM, Charles Constant via swift-evolution <swift-evolution at swift.org <mailto: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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/e8024691/attachment.html>