<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="">My line of thinking is a close variant of this. Usually if I think of the arguments as a potential data structure I pass into the function, then I name the function as if I was passing them all as a single unlabelled argument. <div class=""><br class=""></div><div class="">Usually I think of this as a tuple, so I’m not distracted by whether or not a formal type is needed.<div class=""><br class=""></div><div class="">examples (which work today!):<br class=""><div class=""><br class=""></div><div class="">let origin = (x: 0.0, y:0.0)</div><div class="">func moveTo(x x: Double, y:Double) { print("moved to (\(x), \(y))") }</div><div class="">moveTo(origin)</div><div class=""><br class=""></div><div class="">let userCredentials = (username:”jdoe", password:”abcd1234”) </div><div class="">func logInWith(username username:String, password:String) -> Bool { return true }</div><div class="">logInWith(userCredentials) // my preferred name, since you are giving access to a user and not to credentials</div><div class=""><br class=""></div><div class="">-DW</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 24, 2016, at 1:23 PM, Paul Cantrell via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div></div></div></blockquote><snip></div><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Radek had a nice thought in the aforementioned Gihub thread:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">The rationale being, ifNone doesn't really describe the method … it describes the parameter. Most of the time, the job of the method makes the first parameter obvious (hence the guideline), but here, it doesn't. So the parameter makes sense.<br class=""></blockquote></div><div class=""><br class=""></div><div class="">I’ll give a +1 for these two recommendations from Erica, which run along the same lines as Radek’s thought, but in more thorough detail:</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 23, 2016, at 6:33 PM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><div class=""><b class="">Prefer external names for the first parameter when the natural</b></div><div class=""><div class=""><b class="">semantic relationship between the parameters is stronger than their<br class="">relation to the operation.</b> </div><div class=""><br class=""></div><div class="">For example, the following calls use labels for the first parameter:</div><div class=""><br class=""></div><div class=""><font face="Courier" class="">login(userName: "blah", password: "...")</font></div><div class=""><font face="Courier" class="">moveTo(x: 50.0, y: 30.0)</font></div><div class=""><br class=""></div><div class="">This example is contrary to Swift's normal naming scheme which integrates the</div><div class="">first argument into the function or method name, for example:</div><div class=""><br class=""></div><div class=""><font face="Courier" class="">loginWithUserName("blah", password: "...")</font></div><div class=""><font face="Courier" class="">moveToX(50.0, y: 30.0)</font></div><div class=""><br class=""></div><div class="">The coupling between x and y, username and password, (and yes it is a judgement call) </div><div class="">should be considered as a reason to employ an external label.</div></div></div></div></div></blockquote>…<br class=""><blockquote type="cite" class=""><br class=""></blockquote><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><div class=""><b class="">Differentiate related calls whose implementations are distinguished by their</b></div><div class=""><b class="">parameters, as you would with initializers, using first parameter labels.</b></div><div class=""><b class=""><br class=""></b></div><div class="">Instead of loginWithUserName("blah", password: "...") and loginWithCredential(myCredential),</div><div class="">prefer:</div><div class=""><br class=""></div><div class=""><font face="Courier" class="">login(userName: "blah", password: "...")</font></div><div class=""><font face="Courier" class="">login(credential: myCredential)</font></div></div></div></div></blockquote><br class=""></div><div class="">I’m not sure we’ve found the perfect, crisp way of saying all this — but I strongly agree that the existing guidelines are too rigid on the question of the first arg label, and Erica’s wording comes the closest I’ve seen to being a viable replacement.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div><div class="">Paul</div><div class=""><br class=""></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></div></div></body></html>