<div dir="ltr">The benefit, as I see it, to this approach is not that it reduces noise. It is that it standardizes the naming decision in a broadly applicable manner. Look at the discussion that took place around `union` and `formUnion` to see that this standardization could be beneficial. The argument that this would 'add noise' seems flawed to me, since there is at least as much 'noise' in distinguishing between `sort` and `sorted`.<div><br></div><div>All of that said, I do have a concern that whatever character we use might be too subtle or easily confused with some other meaning. I understand that `&` was just a suggestion but, for example, the proximity to another place where that glyph would be valid and have a different meaning is a potential issue.</div><div><br></div><div>I think that we should seriously consider this, 'noise' ideas aside. If we could agree on a convention that didn't need to consider the specific grammar of the methods, we would have removed a major wrinkle in designing Swift APIs.</div><div><br></div><div>TJ</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 22, 2016 at 8:04 AM, Patrick Smith 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><div>Well, you could actually have something like this now, and use whether the returned result was used or not to know if was a mutating or nonmutating method or not.<br><br><div>Patrick</div><br></div><div><div class="h5"><br><br><br>
<div class="gmail_quote">On Fri, Apr 22, 2016 at 4:53 AM -0700, "James Campbell via swift-evolution" <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="3D"ltr"">
<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">What if we had a concept similar to errors and try ? </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Given this function:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">func sort() -> Self {</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">}</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">mutating sort() -> Self {</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">}</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">If a developer calls:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">array.sort()</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">It will sort a copy of that array, in order to sort in place the developer must confirm the mutation like so:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">mutate array.sort()</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">This will then call the mutating version of sort :)</div></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">
<p><b><font color="#cc0000">___________________________________</font></b></p><p><b>James⎥Chief Of Fun</b></p><p><b><font color="#cc0000"><a href="mailto:james@supmenow.com" target="_blank">james@supmenow.com</a>⎥<a href="http://supmenow.com" target="_blank">supmenow.com</a></font></b></p><p><b><font size="2">Sup</font></b></p><p><b><font size="2">Runway East
</font></b></p><p><b><font size="2">10 Finsbury Square</font></b></p><p><b><font size="2">London</font></b></p><p><b><font size="2">
EC2A 1AF </font></b></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On 22 April 2016 at 12:31, Haravikk 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">This is why I mentioned Xcode; while we can have ampersand as a language feature for marking such things explicitly (i.e- developer consents to doing it), we could also just have Xcode highlight inout parameters and mutating methods differently, but would these represent the same explicit “I know that what I’m doing here will have side-effects” impact (especially if other IDEs add Swift support but don’t do this).<br>
<div><div><br>
> On 22 Apr 2016, at 11:54, Vladimir.S via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> From one point of view, it will be really awesome if we'll have some kind of 'marker' for mutating methods so we can clearly see in code if that method changes the instance(just like we all agree that we must specify & for inout parameter).<br>
><br>
> From other point of view, this will add a much more noise(and typing) in code as we often(in most cases?) use mutating methods. Have a code with a huge number of & symbols(or other) in it - not the best thing.<br>
><br>
> I don't see how we can unite both points.<br>
><br>
> On <a href="tel:22.04.2016%2010" value="+12204201610" target="_blank">22.04.2016 10</a>:00, Tyler Cloutier via swift-evolution wrote:<br>
>> If I recall correctly there was a thread with a similar idea which instead<br>
>> would create a new operator for mutation or a new way of method invocation,<br>
>> such that mutating methods would be called with &. or something similar. e.g.<br>
>><br>
>> foo&.add(5)<br>
>><br>
>> I think the consensus was that that was not a particularly familiar syntax<br>
>> and it would add a decent amount of noise.<br>
>><br>
>> There may have also been some issues with the grammar, I can't recall.<br>
>><br>
>> On Apr 21, 2016, at 11:40 PM, Krishna Kumar via swift-evolution<br>
>> <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>> wrote:<br>
>><br>
>>> Hey<br>
>>><br>
>>> I think adding “&” to methods will reduce the readability of the code.<br>
>>> Also, keyword “mutating” makes it super clear and readable that my method<br>
>>> is mutating the values.<br>
>>><br>
>>> 1. mutating func add(value: Double){…}<br>
>>><br>
>>> 2. func add&(value: Double){…}<br>
>>><br>
>>> I think it’s easy to skip the information encoded into the 2nd function<br>
>>> which is this function is mutating a value as compared to 1st. When I<br>
>>> read 1st function I start reading with keyword “mutating” making its<br>
>>> intentions clear to me.<br>
>>><br>
>>> Also, it might become a symbol nightmare with following type signature of<br>
>>> a function-<br>
>>><br>
>>> func nightmare&(title: String?) -> String? -> String?{…}<br>
>>><br>
>>> I can see the advantage of using “&” when calling a function. It makes<br>
>>> clear at the call site that this method is mutating but still I don’t<br>
>>> find eliminating “mutating” a good step for the reasons mentioned above.<br>
>>><br>
>>> Maybe we can think of some better solution.<br>
>>><br>
>>> Thanks<br>
>>><br>
>>> -Krishna<br>
>>><br>
>>>> On Apr 21, 2016, at 10:38 PM, Daniel Steinberg via swift-evolution<br>
>>>> <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>> wrote:<br>
>>>><br>
>>>> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>><br>
>>><br>
>>> _______________________________________________<br>
>>> swift-evolution mailing list<br>
>>> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<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>
>><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>
>><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>
<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>
</div></div></blockquote></div><br></div>
</div>
</blockquote>
</div>
</div></div></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>