<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="">Hi David,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">sayMessage(“hello”)</div><div class=""><br class=""></div><div class="">would be this instead:</div><div class=""><br class=""></div><div class="">say(message: “hello”)</div><div class=""><br class=""></div><div class="">which isn’t really much of an improvement, in my mind.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">These factors led us to the conclusion that the label of the first argument is (in the vast majority of cases) really <i class="">part of</i> the method and not equal in importance to the remaining labels.</div><div class=""><br class=""></div><div class="">- Tony</div><div class=""><br class=""></div><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>