<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="">On Jan 21, 2016, at 12:07 PM, David Owens II via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><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=""><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="">which isn’t really much of an improvement, in my mind.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Interesting. I would have drawn the opposite conclusion. The vast majority of ObjC APIs have the name of the first parameter in the first section of the selector name. This implies, to me, that the name of the first parameter is very important, and because of the syntactical limitation, the name of the action and the name of the first parameter needed to be joined together.</div><div class=""><br class=""></div><div class="">This leads to APIs like this (from UITableView):</div><div class=""><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><div class=""><font face="Menlo" class="">func registerNib(_ nib: UINib?, forHeaderFooterViewReuseIdentifier identifier: String)</font></div></div></div><div class=""><div class=""><div class=""><font face="Menlo" class="">func registerClass(_ aClass: AnyClass?, forHeaderFooterViewReuseIdentifier identifier: String)</font></div></div></div></blockquote><div class=""><div class=""><br class=""></div><div class="">Instead of APIs like:</div><div class=""><br class=""></div><div class=""><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><font face="Menlo" class="">func register(nib: UINib?, forHeaderFooterViewReuseIdentifier identifier: String)</font></div></div><div class=""><div class=""><font face="Menlo" class="">func register(aClass: AnyClass?, forHeaderFooterViewReuseIdentifier identifier: String)</font></div></div></blockquote><div class=""></div></div><div class=""><br class=""></div><div class="">I don’t think I’m being overly selective in my example, but it seems like overloads make this even more desirable to move the name within the parameter list.</div></div></div></div></blockquote><br class=""></div><div>The others’ are right, this is best discussed holistically as part of the forthcoming renamification threads.</div><div><br class=""></div><div>That said, the example you picked is exactly illustrative of why the current default works well. One of the principles of the naming guidelines is “omit needless words”: <a href="https://swift.org/documentation/api-design-guidelines.html" class="">https://swift.org/documentation/api-design-guidelines.html</a> and it is a specific anti-goal of the new naming approach to “simply repeat type information” in an argument name.</div><div class=""><br class=""></div><div>This approach will lead to these APIs actually being imported as:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>func register(nib: UINib?, ...<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func register(aClass: AnyClass?, …<br class=""><br class=""></div><div>These are much better at point of use, and dovetails perfectly with our current keyword argument behavior.</div><div><br class=""></div><div>-Chris</div></body></html>