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

[Michael Wells]

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

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