<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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. <br class=""><br class="">-mw<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 21, 2016, at 9:23 AM, David Owens II via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Ok, this is something that's bugged me since Swift was released. It was <i class="">almost</i> 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).<div class=""><br class=""></div><div class="">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? </div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""> func say(message: String, times: Int) { ... } // or</font></div><div class=""><font face="Menlo" class=""> func sayMessage(message: String, times: Int) { ... }</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class=""> say("hello world", times: 5) // or</font></div><div class=""><font face="Menlo" class=""> sayMessage("hello world", times: 5)</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class=""> // vs.</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class=""> say(message: "hello world", times: 5)</font></div><div class=""><br class=""></div><div class="">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...).</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">The seemingly poor choice of this shows up in other places too, like Doug Gregor's <i class="">Naming Functions with Arguments Labels</i> proposal. The default for that is to always have the _ in the first name slot.</div><div class=""><br class=""></div><div class=""><div class=""><font face="Menlo" class=""> say(_:times:)</font></div></div><div class=""><font face="Menlo" class=""> sayMessage(_:times:)</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class=""> // vs.</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class=""> say(message:times:)</font></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Am I just missing the really compelling rationale for this?</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">David</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>