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

[Charles Constant]

+1 (assuming the OP means making naming consistent)

This is one of the ugliest aspects of Swift. There has to be some other way
to ensure compatibility with Obj-C. This is particularly cruel to
beginners, who won't understand why they can't write arguments the same way
everywhere. It's also additional complexity for anyone reading a function.

My personal preference is that **all** arguments, not just regardless of
position, but also regardless of their being in an init/method, have
explicit labels by default. If one wants to override that with "_", one can
do so, but it ought to work the same way everywhere.



On Thu, Jan 21, 2016 at 11:25 AM, Tony Parker via swift-evolution <
swift-evolution at swift.org> wrote:

> Hi David,
>
> This is obviously a topic which gets a lot of discussion, and I doubt I’ll
> be able to thoroughly convince anyone with an email or two on the topic…
> but I would like to share one of the reasons behind the decision to avoid
> labeling the first argument.
>
> We surveyed the entire surface area of the iOS and OS X SDKs, looking to
> see how many arguments typical methods had. We found that the vast majority
> of methods actually have just one argument. If we went with a rule that
> first arguments should be named, then methods like:
>
> sayMessage(“hello”)
>
> would be this instead:
>
> say(message: “hello”)
>
> which isn’t really much of an improvement, in my mind.
>
> Furthermore, when methods have more than one argument, we found that the
> additional arguments are most often modifiers or minor adjustments to the
> first argument. Or, put another way: when there are multiple arguments, the
> first argument is almost always far more important to the meaning of the
> method. Your example below follows this pattern as well: the primary
> purpose of the function is to say a message. The number of times it is said
> is a secondary modifier to the central purpose.
>
> These factors led us to the conclusion that the label of the first
> argument is (in the vast majority of cases) really *part of* the method
> and not equal in importance to the remaining labels.
>
> - Tony
>
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160121/33c2065d/attachment.html>