<html><head></head><body><div>Yes +1 I think how the compiler can’t work with two methods with the same name, where one has a result, and other mutating, needs to be fixed to enable nice APIs.<br><br><div class="acompli_signature">Patrick</div><br></div><br><br><br>
<div class="gmail_quote">On Sun, Apr 24, 2016 at 2:33 AM -0700, "James Froggatt 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"">
<pre>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.
Have we considered this, then:
a.union(b) //mutating
_ = a.union(b) //non-mutating
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.
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.
>From James F
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
</pre>
</div>
</blockquote>
</div>
</body></html>