<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 30, 2016, at 11:43 AM, Scott James Remnant 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=""><div class="">-1<br class=""><br class="">This proposal doesn’t even use Swift naming style to make its point, as soon as you do, the reason why Swift considers argument labels to be part of the type signature becomes apparent. <br class=""><br class="">The author of the proposal uses the following example:<br class=""><br class=""> func doSomething(x: Int, y: Int) -> Bool<br class=""><br class=""><br class="">This is just not Swift-y, a much better example would be:<br class=""><br class=""> func sinkBattleship(atX x: Int, y: Int) -> Bool<br class=""><br class=""></div></div></blockquote><div><br class=""></div><div><pedanticism></div><div>If you want to talk about pedantic following of API naming guidelines for example code, then I believe that your example also runs afoul. It would be:</div><div><br class=""></div><div>func sinkBattleshipAt(x: Int, y: Int) -> Bool</div><div><br class=""></div><div>Due to a special case where the preposition covers multiple arguments. This arrises mostly from flatten-ed structs as parameters, e.g. from old C APIs predating struct literal syntax. See:</div><div><br class=""></div><div><ul style="box-sizing: border-box; margin: 1em 0px; padding: 0px 0px 0px 40px; list-style-position: initial; list-style-image: initial; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, Arial, Verdana, sans-serif; font-size: 18px;" class=""><li style="box-sizing: border-box; margin: 0px; padding: 0px;" class=""><div class="more" style="box-sizing: border-box; transition: opacity 0.5s ease, max-height 0.5s ease; -webkit-transition: opacity 0.5s ease, max-height 0.5s ease; visibility: visible; max-height: 1000rem;"><p style="box-sizing: border-box; margin: 0px 0px 1.5em; padding: 0px;" class="">An exception arises when the first two arguments represent parts of a single abstraction.</p><div class="bad highlighter-rouge" style="box-sizing: border-box;"><pre class="highlight" style="box-sizing: border-box; margin: 0.5em 0.5em 1.5em 10px; padding: 0.5em 0.5em 0.5em 1em; font-size: 14px; line-height: 18px; border-left-width: 3px; border-color: rgb(246, 183, 190); border-left-style: solid; overflow: visible; font-family: Menlo, Consolas, Monaco, 'Courier New', monospace, serif; background-color: rgb(249, 226, 228);"><code style="box-sizing: border-box; font-size: 1em; white-space: inherit; font-family: Menlo, Consolas, Monaco, 'Courier New', monospace, serif;" class="">a.move(<strong style="box-sizing: border-box;" class="">toX:</strong> b, <strong style="box-sizing: border-box;" class="">y:</strong> c)
a.fade(<strong style="box-sizing: border-box;" class="">fromRed:</strong> b, <strong style="box-sizing: border-box;" class="">green:</strong> c, <strong style="box-sizing: border-box;" class="">blue:</strong> d)
</code></pre></div><p style="box-sizing: border-box; margin: 0px 0px 1.5em; padding: 0px;" class="">In such cases, begin the argument label <em style="box-sizing: border-box;" class="">after</em> the preposition, to keep the abstraction clear.</p><div class="good highlighter-rouge" style="box-sizing: border-box;"><pre class="highlight" style="box-sizing: border-box; margin: 0.5em 0.5em 1.5em 10px; padding: 0.5em 0.5em 0.5em 1em; font-size: 14px; line-height: 18px; border-left-width: 3px; border-color: rgb(192, 255, 188); border-left-style: solid; overflow: visible; font-family: Menlo, Consolas, Monaco, 'Courier New', monospace, serif; background-color: rgb(230, 255, 229);"><code style="box-sizing: border-box; font-size: 1em; white-space: inherit; font-family: Menlo, Consolas, Monaco, 'Courier New', monospace, serif;" class="">a.moveTo(<strong style="box-sizing: border-box;" class="">x:</strong> b, <strong style="box-sizing: border-box;" class="">y:</strong> c)
a.fadeFrom(<strong style="box-sizing: border-box;" class="">red:</strong> b, <strong style="box-sizing: border-box;" class="">green:</strong> c, <strong style="box-sizing: border-box;" class="">blue:</strong> d)
</code></pre></div></div></li></ul><div class=""><font color="#333333" face="Helvetica Neue, Helvetica, Arial, Verdana, sans-serif" size="4" class=""><br class=""></font></div></div><div><div></pedanticism></div><div class=""><br class=""></div></div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">the proposal states that the argument labels be then stripped from the type, which would make this method type-compatible with:<br class=""><br class=""> func meetsBattingAverage(ofHits hits: Int, forRuns runs: Int) -> Bool<br class=""><br class=""><br class="">I don’t think it’s desirable for this to work at all… Argument labels are not parameter names, they are a first class part of Swift’s type system, and always meaningful when employed properly.<br class=""><br class=""><br class="">Scott<br class="">_______________________________________________<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></div></blockquote></div><br class=""></body></html>