<div dir="ltr">On Sun, Apr 24, 2016 at 11:01 AM, Tim Vermeulen via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> The idea of distinguishing all mutating/non-mutating functions with only the assignment operator did occur to me as I wrote that.<br>
> Using such a rule would allow automatic generation of mutating methods from non-mutating ones, since the naming would no longer need changing.<br>
> However, this would also mean scrapping half the Naming Guidelines, so I'm hesitant to put that possibility forward as a serious proposal.<br>
><br>
> I think union (verb) vs union (noun) would work as a one off, though, since it fits the guidelines as they currently stand. It would be a nice way to demonstrate that the compiler can make the distinction in a public API.<br>
><br>
> > From James F<br>
> On 24 Apr 2016, at 15:49, Tim Vermeulen<<a href="mailto:tvermeulen@me.com">tvermeulen@me.com</a>>wrote:<br>
><br>
> > > The whole naming issue seems to be caused by the .union(_:) function. The Swift Guidelines say that mutating functions should use a verb, and non-mutating forms should use a noun, but in this case, the word union itself is a verb and a noun.<br>
> > ><br>
> > > Have we considered this, then:<br>
> > ><br>
> > > a.union(b) //mutating<br>
> > ><br>
> > > _ = a.union(b) //non-mutating<br>
> > ><br>
> > > There is no ambiguity in most situations, and the fact the Swift compiler can't disambiguate this at the moment is a bug I'd like to see fixed in the Swift 3 timeframe. I think this wouldn't be such a bad compromise, and other functions could still use the standard -ed/-ing system alongside this without the API looking inconsistent, unlike with the form- prefix.<br>
> > ><br>
> > > Admittedly, there is merit to the idea that functional methods should make non-mutating forms the primary form, but I feel like we should figure out what our stance is on this methodology in general. A mention in the Guidelines one way or the other would be nice, since the current rules seem to support this.<br>
> > ><br>
> > > > From James F<br>
> ><br>
> > Can’t we do this for every mutating method? i.e.<br>
> ><br>
> > var numbers = [1,3,2]<br>
> > let sorted = numbers.sort()<br>
> > // sorted is [1,2,3], numbers is [1,3,2]<br>
> > numbers.sort()<br>
> > // numbers is [1,2,3]<br>
> ><br>
> > I suppose this would require that the mutating version doesn’t return anything, and I don’t know if that’s ever a problem.<br>
><br>
><br>
><br>
<br>
</span>Well, this change would render a big part of the naming guidelines meaningless, but isn’t that a good thing? Guidelines are often in place to prevent ambiguity, and this solution would do that without the need for guidelines.<br>
<br>
Anyways, I wouldn’t be surprised if this idea has come up before and has been rejected, but to me it sounds like a good idea.<br></blockquote><div><br></div><div>Yes, I suggested this a while back, and it was rejected.</div><div><br></div><div><br></div></div></div></div>