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

David Owens II david at owensd.io
Thu Jan 21 11:23:37 CST 2016


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


More information about the swift-evolution mailing list