
<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=""><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="">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 class=""><br 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 class=""><br class=""></div><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="font-variant-ligatures: no-common-ligatures; color: #000000" 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="font-variant-ligatures: no-common-ligatures; color: #000000" class="">say(</span>"Hello"<span style="font-variant-ligatures: no-common-ligatures; color: #000000" class="">, </span><span style="font-variant-ligatures: no-common-ligatures; color: #272ad8" class="">4</span><span style="font-variant-ligatures: no-common-ligatures; color: #000000" 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 class=""><br class=""></div><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 class="">Higher-order functions already ignore labels completely and rely on positions only.</div><div class=""><br class=""></div><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 class=""><br class=""></div><div class="">Tino</div></div></body></html>