<div dir="ltr">1. -> Strong +1<div>2. -> I do not know if this is the best syntax solution, but it appears a good start.</div><div><br></div><div>-Van</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 31, 2016 at 10:27 PM, Howard Lovatt via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I would suggest two language changes that embrace argument labels as the norm in Swift:<div><br></div><div> 1. All arguments, functions and initialisers, to be labelled as the default in the language, i.e. no special first argument that is unlabelled.</div><div> 2. An argument with a default value may be called by specifying the label with no value as well as omitting the value as well as specifying the value, e.g. in `Array` the drop methods could be `func drop(first n: Int = 1)` and `func drop(last n: Int = 1)` and could be called `array.drop(first:)` and `array.drop(last:)` and `array.drop()` would be an ambiguity error. Thus two functions replace four in `Array`.<br><div><br></div><div>With these two changes the guidelines could be:<div><br></div><div> "All arguments are labelled, e.g. `moveTo(x: 1.0, y: 0.5)`; unless the arguments are truely interchangeable and no further clarification is required, e.g. `max(x1, x2)`. The degenerate case of the exception is functions with one argument; in which case if no further clarification is required then no label is required, e.g. `sort(<)`. Clarification via an argument label is required if the call reads better, e.g. `array.removeAll(keepCapacity: true)`, or because it is clearer in the case of overloads, e.g. `array.append(x)` and `array.append(contentsOf: x)`."</div></div></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On 1 February 2016 at 10:08, Dave Abrahams via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
on Sun Jan 31 2016, Paul Cantrell <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
<br>
>> On Jan 29, 2016, at 10:29 AM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> Differentiate related calls whose implementations are distinguished<br>
>> by their parameters, as you would with initializers, using first<br>
>> parameter labels.<br>
><br>
>> …<br>
>> Prefer external names for the first parameter when the natural<br>
>> semantic relationship between the parameters is stronger than their<br>
>> relation to the operation.<br>
>><br>
>> For example, the following calls use labels for the first parameter:<br>
>><br>
>> login(userName: "blah", password: "...")<br>
>> moveTo(x: 50.0, y: 30.0)<br>
>> constructColor(red: 0.2, green: 0.3, blue: 0.1)<br>
>><br>
>> This example is contrary to Swift's normal naming scheme which<br>
>> integrates the first argument into the function or method name, for<br>
>> example:<br>
>><br>
>> loginWithUserName("blah", password: "...")<br>
>> moveToX(50.0, y: 30.0)<br>
>> constructColorWithRed(0.2, green: 0.3, blue: 0.1)<br>
>><br>
>> The relationships between (x, y), (username, password), and (red,<br>
>> green, blue) are strong enough to allow you to make a judgement call<br>
>> to employ an external label.<br>
>><br>
><br>
> An anecdote in support of Erica’s thinking in the ongoing Battle of the First Argument Labels:<br>
><br>
> I mentioned the ongoing swift-evolution debates to Bret Jackson, one<br>
> of my Macalester colleagues — awesome developer, 3D / VR / HCI<br>
> researcher, tons of C++ experience, never seen Swift before — and<br>
> typed out this example for him:<br>
><br>
> moveTo(1.0, y: 0.5)<br>
><br>
> …and then this (he nods approvingly):<br>
><br>
> moveTo(x: 1.0, y: 0.5)<br>
><br>
> …and then this:<br>
><br>
> moveToX(1.0, y: 0.5)<br>
><br>
> …at which point, before I’d even finished typing it out, he physically<br>
> recoiled in revulsion, threw hand up in front of his face, and let out<br>
> a pained “oh please no!!” I wish I had video of him squirming in his<br>
> chair. It was something to behold.<br>
><br>
> Thus my N=1 study of Swift newcomers concludes that “moveToX” is horrifying.<br>
<br>
a. I agree; it's not me you need to convince.<br>
<br>
b. The guidelines working group is reluctant to add special-case<br>
guidelines. It would be better to have one guideline that works for<br>
all the cases where first arguments should have a label, including<br>
those that have only one argument. For example, “first arguments<br>
that are not direct objects should be labeled when it doesn't merely<br>
repeat type information.”<br>
<span><font color="#888888"><br>
--<br>
-Dave<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div> -- Howard.<br></div>
</font></span></div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>