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

[Sean Heber]

I’m of two minds about this. I initially really disliked this convention and thought it would be more Swifty to get rid of the implicitly unnamed first parameter and do things as David suggests, but lately I have found the naming convention useful for forcing me to keep functions simpler and smaller because the addition of a second parameter that must be named feels so out of place at the call site by comparison and I’d rather not have it there if I can avoid it. Of course there is no reason such discipline could not be applied without this convention, it’s just that, at the moment, I’ve come to embrace the design as a tool for producing better code. I don’t know if that was the original intent behind it or not, though.

l8r
Sean


> On Jan 21, 2016, at 12:11 PM, Michael Wells via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I’m in 100% agreement here. In this case, the Swift API Design Guideline seems to be aligned more with Objective C and it doesn’t feel  at all Swift-y. 
> 
> -mw
> 
>> 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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution