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

[Maximilian Hünenberger]

See below

> Am 21.01.2016 um 19:11 schrieb Michael Wells via swift-evolution <swift-evolution at swift.org>:
> 
> 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? 
>> 

As you said in some cases. So in most cases you want to have an implicit unnamed first parameter.

- Maximilian

>>     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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160121/9f98749e/attachment.html>