<div dir="ltr">Think of the name of the mutating method sort as `mutating sort`, i.e. a different name than `sort` and therefore not an overload. This way the call and declaration match:<div><br></div><div> struct Array<T>: ... { </div><div> func mutating sort(...) { ... } </div><div> func sort(...) -> [T] { ... }</div><div> }</div><div> </div><div> mutating array.sort(>)</div><div> let sorted = array.sort(>)</div><div><br></div><div>As a critique of the `func mutating <name>` proposal consider:</div><div><br></div><div> protocol P {</div><div> func mutating p()</div><div> func p()</div><div> }</div><div> </div><div> class AP: P {</div><div> func mutating p() { ... } // `mutating` not currently allowed in a class</div><div> func p() { ... }</div><div> }</div><div> </div><div> let aP = AP()</div><div> mutating aP.p() // Odd since `aP` is a let - but would everyone get used to it quickly and realize that what `aP` points to is mutated</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"> -- Howard.<br></div></div>
<br><div class="gmail_quote">On 28 April 2016 at 07:50, Michael Peternell <span dir="ltr"><<a href="mailto:michael.peternell@gmx.at" target="_blank">michael.peternell@gmx.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Isn't there a strong convention that overloaded methods should be very similar? Like a print function that takes a String and a print function that takes an Int? Having two 'sort' functions that are not even similar, but that just refer to the same concept ('sorting') seems confusing, and I haven't seen this in any other language so far. I think overloading is a somewhat advanced topic, and programming beginners should be allowed to be ignorant about this feature and just think "print is a function that prints its argument to the console" or "sort is a function that sorts a sequence" - not having to care if the function is overloaded or not. (I know that print() is not an overloaded function is Swift, this was just an example.)<br>
<br>
-Michael<br>
<br>
> Am 27.04.2016 um 23:13 schrieb Howard Lovatt via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br>
><br>
> Personally I like the xxx and xxxed naming, e.g. sort and sorted, and think it should be universally applied, e.g. union and unioned.<br>
><br>
> However that proved unpopular and we ended up with a hybrid with sort and sorted but union and formUnion. Which no one seems to like!<br>
><br>
> Therefore I suggest a new review for the proposed:<br>
><br>
> mutating array.sort(<)<br>
> let sorted = array.sort(<)<br>
> mutating set.union(other)<br>
> let unioned = set.union(other)<br>
><br>
> I think the motivation for new review, or new information if you like, is the discussion didn't cease after the decision was taken, unlike most discussions on swift-evolution.<br>
><br>
> On Wednesday, 27 April 2016, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
><br>
> Sent from my iPad<br>
><br>
> On Apr 27, 2016, at 12:37 AM, Thorsten Seitz via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
>> Am 26. April 2016 um 22:02 schrieb Dave Abrahams <<a href="mailto:dabrahams@apple.com">dabrahams@apple.com</a>>:<br>
>><br>
>>><br>
>>> on Tue Apr 26 2016, Thorsten Seitz <tseitz42-AT-icloud.com> wrote:<br>
>>><br>
>>>> Am 23.04.2016 um 10:27 schrieb Pyry Jahkola via swift-evolution<br>
>>>> <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br>
>>>><br>
>>>> I'd like to second James Campbell's suggestion of a `mutate` keyword.<br>
>>>> Clarifying comments inline below:<br>
>>>><br>
>>>> On 23 Apr 2016, at 00:24, Dave Abrahams via swift-evolution<br>
>>>> <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>>>><br>
>>>> This is not a new idea. Something almost identical to this has been<br>
>>>> explored and discussed quite thoroughly already:<br>
>>>> <<a href="https://github.com/apple/swift/blob/master/docs/proposals/Inplace.rst" rel="noreferrer" target="_blank">https://github.com/apple/swift/blob/master/docs/proposals/Inplace.rst</a>>.<br>
>>>> In fact, it was implmented and later reverted because it raised<br>
>>>> language-design questions for which we had no good answers.<br>
>>>><br>
>>>> I don't know if the following are particularly good answers, but I'll try<br>
>>>> anyway:<br>
>>>><br>
>>>> I don't believe the choice of glyph (& vs =) affects any of the<br>
>>>><br>
>>>> fundamental issues:<br>
>>>><br>
>>>> * Should the x.=f() syntax be required for *every* mutating method<br>
>>>> invocation?<br>
>>>><br>
>>>> Allow me to ask it differently: Should some specific syntax be required for<br>
>>>> every mutating method? — Yes.<br>
>>>><br>
>>>> I think I like that idea.<br>
>>>><br>
>>>> Should the syntax be `x.=f()`? — Not necessarily. I kinda like James<br>
>>>> Campbell's idea of a `mutate` keyword. Consider the following:<br>
>>>><br>
>>>> var numbers = [5, 12, 6, 2]<br>
>>>> mutate numbers.append(10)<br>
>>>> mutate numbers.sort()<br>
>>>> if let biggest = mutate numbers.popLast() {<br>
>>>> print("The biggest number was:", biggest)<br>
>>>> }<br>
>>>><br>
>>>> So `mutate` would work much like `try` but—unlike `try` which can move<br>
>>>> further to the left—`mutate` would have to always prefix the mutating<br>
>>>> receiver.<br>
>>>><br>
>>>> That doesn't look so bad (we might shorten 'mutate' to 'mut', though I don't<br>
>>>> think that would be really necessary).<br>
>>><br>
>>> We've already discussed this whole question length, specifically<br>
>>> considered the direction of an almost-identical language feature, and<br>
>>> ended up settling on the “form/ed/ing” naming conventions. If there is<br>
>>> some new information since then, it would be possible to handle<br>
>><br>
>> The new information might be that the "form" naming conventions have not been that well received, i.e. the naming discussion cannot really be described as "settled" :-)<br>
><br>
> Also, I could be wrong but IIRC the discussion of having some kind of "mutation" syntax post Swift 3 was held open when that discussion concluded. It was just out of scope for Swift 3 to address all of the necessary issues.<br>
><br>
> I hope this issue isn't settled once and for all as I am not very happy with the current solution. The "form" names are quite awkward and confusing IMO. I would eventually get used to them but that is the problem - they will really take getting used to.<br>
><br>
><br>
>><br>
>> -Thorsten<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>
<span class="HOEnZb"><font color="#888888">><br>
> --<br>
> -- Howard.<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>
</font></span></blockquote></div><br></div>