<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 Jan 22, 2016, at 6:26 AM, Tino Heth via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br 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="">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></div></blockquote></div>It's definitely confusing that labels receive special treatment in init, and I'm quite sure method declarations would look different without the "Objective-C-legacy”.</div></div></blockquote><div><br class=""></div><div>We believe fairly strongly that Swift’s design here reflects the appropriate defaults for clear, expressive APIs and code. The API Design Guidelines line up with the default behavior of Swift for a reason. Repeating the “Objective-C legacy” trope strongly implies that you’re not considering the rationale behind Swift’s design, and weakens your arguments considerably.</div><div><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=""><div class="">Imho named arguments with default values are a great feature, which I loved since I've seen it the first time R (which would be very hard to use without default values…).</div><div class="">R, as my reference, is quite flexible with parameters:</div><div class="">You can leave out all labels, and only rely on the order of the values, you can assign values in whatever order you like — and, up to a certain degree, you can mix:</div><div class="">myFunc(firstParameterWithoutLabel, secondParameterWithoutLabel, fourthLabel = 8, thirdLabel = 0.5)</div><div class=""><br class=""></div><div class="">I don't think Swift needs that much flexibility, but imho the compiler could be less strict and leave it to the user weather parameters are identified via label or position.</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class="">say(<span style="font-variant-ligatures: no-common-ligatures; color: #d12f1b" class="">"message"</span>, times: <span style="font-variant-ligatures: no-common-ligatures; color: #272ad8" class="">4</span>)</div></div><div class="">is a good default and should be offered by autocompletion, but</div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><br class=""></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class="">say(message: <span style="font-variant-ligatures: no-common-ligatures; color: #d12f1b" class="">"Hello"</span>, times: <span style="font-variant-ligatures: no-common-ligatures; color: #272ad8" class="">4</span>)</div></div></div></div></div></blockquote><div><br class=""></div><div>The message is the direct object of the verb “say”, so the first argument being the message is implied. Clarity is not improved by having the “message:” argument label.</div><div><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=""><div class="">and even</div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(209, 47, 27);" class=""><span style="" class=""><br class=""></span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(209, 47, 27);" class=""><span style="" class="">say(</span>"Hello"<span style="" class="">, </span><span style="font-variant-ligatures: no-common-ligatures; color: #272ad8" class="">4</span><span style="" class="">)</span></div></div><div class=""><br class=""></div><div class="">could be allowed as well (as long as there is no clash with a second say-function).</div></div></div></div></blockquote><div><br class=""></div><div>This is less clear than your initial example. There is absolutely nothing to indicate, at the call site, that “4” is a repeat count.</div><br 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=""><div class="">Labels are "just" an aid for programmers, but for the program itself, they have not much more meaning than a comment:</div></div></div></div></blockquote><div><br class=""></div><div>That is incorrect. The argument labels are a fundamental part of the name of a Swift function (or initializer, or subscript).</div><br 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=""><div class="">Higher-order functions already ignore labels completely and rely on positions only.</div></div></div></div></blockquote><div><br class=""></div><div>That’s mostly correct; our model around argument labels with function types is fuzzy and needs work.</div><br 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=""><div class="">So, instead of complicated rules enforced by the compiler, I would prefer a simple system backed by conventions that discourage programmers to fall back to C-style calls where you have to count parameters to decipher their meaning.</div></div></div></div></blockquote><br class=""></div><div>So… you want a plethora of conventions that differ from one project to the next, rather than a set of default language rules backed by the API Design Guidelines? I admit that one will often do a double-take when first encountering the rules for which arguments have labels by default, but I’d rather learn that once than have widely differing approaches to when argument labels are provided vs. dropped.</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>- Doug</div><div><br class=""></div><br class=""></body></html>