<div dir="ltr">Looking at other languages:<div><br></div><div><ol><li>A Java like API would be: </li><ul><li>mutating func remove(T) -&gt; Void</li><li>mutating func remove&lt;S: SequenceType ...&gt;(all: S) -&gt; Void</li><li>func removed(T) -&gt; Self</li><li>func removed&lt;S...&gt;(all: S) -&gt; Self</li><li>Similarly for retain and add<br></li></ul><li>In Scala they primarily use operators, so a Scala like API would be: </li><ul><li>func -=(inout Self, T) -&gt; Void</li><li>func -=&lt;S: SequenceType ...&gt;(inout Self, S) -&gt; Void</li><li>func -(T) -&gt; Self</li><li>func -&lt;S...&gt;(all: S) -&gt; Self</li><li>Similarly for &amp; and +<br></li></ul></ol><div><br></div>Either of these naming patterns seems better than those proposed :(.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">  -- Howard.<br></div></div>
<br><div class="gmail_quote">On 4 April 2016 at 15:49, Thorsten Seitz via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div></div><div>I think Michel and Shawn did raise some good points here.</div><div><br></div><div>-Thorsten </div><div><br>Am 03.04.2016 um 22:27 schrieb Shawn Erickson via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; What is your evaluation of the proposal?<br>
<br>
I don&#39;t like &quot;form&quot; as a prefix. To me there is no difference between `union` and `formUnion`: both sounds functional-style, and actually the second one perhaps a bit more to my ears. There&#39;s basically two dictionary definitions of &quot;form&quot;:<br>
<br>
1. &quot;bring together parts or combine to create (something)&quot; which to me implies a new value is created, and<br>
2. &quot;make or fashion into a certain shape or form&quot; which would imply that the material you start with is transformed, which is apparently the intended meaning and also the reverse meaning from the above.<br>
<br>
I mean, doesn&#39;t this make sense as an API?<br>
<br>
        let donut = baker.formDonut(dough) // non-mutating<br>
<br>
Perhaps instead of &quot;form&quot; we could use &quot;become&quot; as a prefix when the operation is naturally described by a noun. That would seem less ambiguous to me:<br>
<br>
        a.becomeUnion(b)<br>
        a.becomeIntersection(b)<br>
        a.becomeSuccessor(b)<br>
<br>
It&#39;s a bit passive, but I find it fits well when the operation is a noun.<br>
<br>
And there&#39;s no way the term lends itself to non-mutating cases without things becoming nonsensical:<br>
<br>
        let donut = baker.becomeDonut(dough) // non-mutating?<br></blockquote><div><br></div></div><div dir="ltr"><div class="gmail_quote"><div>I also am having difficulty coming to terms with the use of &quot;form&quot; (I am a native English speaker). As you note &quot;form&quot; can imply the creation of something from parts (more like assembling a new thing) as well as the creation of something out of a material say a of block clay (more like molding something out of an existing thing). It doesn&#39;t seem clear cut to me to imply in place mutation.</div><div><br></div><div>Additionally my eyes / brain keep seeing &quot;from&quot; instead of &quot;form&quot;. This type of issue is generally true with any short word made up of the same set of letters (made worse since &quot;from&quot; is more common in programming then &quot;form&quot;). The mind quickly narrows in on a set of possible words given the letters we see and then uses context to help get the correct one and/or additional visual parsing to understand the exact ordering of letters (more energy expended). Anyway since I keep seeing &quot;from&quot; instead of &quot;form&quot; I keep going in the direction of thinking it returns something made from the two (or more) items involved (not really sure why &quot;from&quot; goes that direction in my head, it could also go the in place direction).</div><div><br></div><div>I would prefer something other then &quot;form&quot; (note I just typed &quot;from&quot; by mistake)... I think your suggestion of &quot;become&quot; has merit.</div><div><br></div><div>y.becomeUnion(x) --reads to me as--&gt; &quot;y become union with x&quot;</div><div>y.formUnion(x) --read to me as--&gt; &quot;y from oops... y forming a union of x&quot;</div><div>y.becomeI<span style="color:rgb(0,0,0)">ntersection</span>(x) --reads to me as--&gt; &quot;y become intersection with x&quot;</div><div></div><div>y.form<span style="color:rgb(0,0,0)"><span style="color:rgb(0,0,0)">I</span><span style="color:rgb(0,0,0)">ntersection</span></span>(x) --read to me as--&gt; &quot;y from oops... y forming an intersection with x&quot;<br></div><div><br></div><div>In the &quot;forming&quot; situations it – to me – is ambiguous on if that is in place or not. To me it implies more of giving something new back.</div><div><span style="color:rgb(0,0,0)"><br></span></div><div>I am -1 on &quot;form&quot; aspect of this proposal. ...of course things are learnable as long as things are fairly consistent and not to far out of the norm for typical language use. Personally I don&#39;t see &quot;form&quot; as that typical in English.</div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div><div>-Shawn</div><div><br></div><div><br></div></div></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></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>