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

[Adriano Ferreira]

I totally understand that beautiful & elegant code might be very subjective. However, having a different way of treating the first parameter is rather confusing. Feels weird, inconsistent, and introduces complexity.

I’d rather have all arguments with explicit labels by default. Simple and clean. And, as mentioned already, if one wants to override that behaviour, just use `_`.

Best,

— A

> On Jan 21, 2016, at 12:23 PM, 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/51c7c656/attachment.html>