<div style="white-space:pre-wrap">Agreed that &quot;union&quot; creates an expectation that it&#39;s non-mutating.<br><br>There&#39;s no real point in pushing back on whether UIs are more or less important for Swift than math.<br><br>Problem is, the moment you name something SetAlgebra, you&#39;ve set user expectations that it&#39;s a &#39;math API&#39;. Those ain&#39;t UI terms.<br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 15, 2016 at 11:25 AM Dave Abrahams via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">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"><br>
on Mon Feb 15 2016, Maximilian Hünenberger &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
<br>
&gt; I also prefer (2). Isn&#39;t &quot;union&quot;, &quot;intersection&quot;, ... a &quot;Term of Art&quot;?<br>
&gt; See the guidelines under &quot;Stick to the established meaning&quot;.<br>
&gt;<br>
&gt; So we should stick to the mathematical naming.<br>
<br>
My understanding of the rationale for the current direction is that the<br>
domain of building GUI apps is more important than that of math, so the<br>
look and feel of sets should match those of most other (non-math) APIs.<br>
<br>
&gt; Since these terms almost always return a new instance we should have<br>
&gt; an obvious mutating version with an &quot;inPlace&quot; suffix.<br>
&gt;<br>
&gt; - Maximilian<br>
&gt;<br>
&gt;&gt; Am 14.02.2016 um 22:37 schrieb Xiaodi Wu via swift-evolution<br>
&gt;&gt; &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;:<br>
&gt;&gt;<br>
&gt;&gt; From a 10,000-ft view, I&#39;d suggest that the noun/verb rule<br>
&gt;&gt; consistently runs into a problem with mathematical terms.<br>
&gt;&gt;<br>
&gt;&gt; In general, mathematical functions don&#39;t have verb forms. You<br>
&gt;&gt; &#39;compute&#39; the reciprocal, or &#39;find&#39; the reciprocal, or &#39;take&#39; the<br>
&gt;&gt; reciprocal, you don&#39;t &#39;reciprocate&#39; or &#39;reciprocalize&#39;. Likewise for<br>
&gt;&gt; trigonometric functions, etc. Nor can you really &#39;cross produce&#39;...<br>
&gt;&gt;<br>
&gt;&gt; So consistent is this trend that where two words might be noun/verb<br>
&gt;&gt; counterparts, like intersect/intersection and<br>
&gt;&gt; transform/transformation, common math usage treats both as<br>
&gt;&gt; acceptable nouns.<br>
&gt;&gt;<br>
&gt;&gt; In colloquial usage, you might verb the noun, but then by definition<br>
&gt;&gt; the verb and noun become the same. Then, to generate a noun<br>
&gt;&gt; phrase/participle/etc. that looks different from the verb, you have<br>
&gt;&gt; to noun-ify the verbed noun.<br>
&gt;&gt;<br>
&gt;&gt; Without an exception for mathematical function names, the only<br>
&gt;&gt; solution to fulfill these new Swift rules are clobbering the<br>
&gt;&gt; well-known math name or not using the math name at all. Indeed all<br>
&gt;&gt; proposed solutions so far come down to one of four options, either<br>
&gt;&gt; applied globally or only to sets for now, punting the rest down the<br>
&gt;&gt; road:<br>
&gt;&gt;<br>
&gt;&gt; (1) Abandon the rule, making a new one (e.g.: .=)<br>
&gt;&gt; (2) Make an exception to the rule for math function names<br>
&gt;&gt; (3) Generate the least offensive noun-ified verbed nouns based on math function names<br>
&gt;&gt; (4) Don&#39;t use math function names<br>
&gt;&gt;<br>
&gt;&gt; (1) is off the table, according to the core team. My vote at this<br>
&gt;&gt; point is for (2), and I see that a few others have voiced that<br>
&gt;&gt; opinion. It&#39;d be nice to get a sense from the core team if that is<br>
&gt;&gt; even a possibility. (3) has elicited a lot of discussion and<br>
&gt;&gt; visceral reactions. (4) might be workable for sets alone but surely<br>
&gt;&gt; can&#39;t be a generalized solution for all mathematical concepts to be<br>
&gt;&gt; encountered in Swift.<br>
&gt;&gt; On Sun, Feb 14, 2016 at 3:14 PM Tyler Fleming Cloutier via<br>
&gt;&gt; swift-evolution<br>
&gt;&gt; &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt; On Feb 14, 2016, at 12:48 PM, Dave Abrahams<br>
&gt;&gt;&gt;&gt; &lt;<a href="mailto:dabrahams@apple.com" target="_blank">dabrahams@apple.com</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; on Sun Feb 14 2016, Tyler Fleming Cloutier &lt;cloutiertyler-AT-aol.com&gt; wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; On Feb 14, 2016, at 8:27 AM, Dave Abrahams<br>
&gt;&gt;&gt;&gt;&gt;&gt; &lt;<a href="mailto:dabrahams@apple.com" target="_blank">dabrahams@apple.com</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; on Sat Feb 13 2016, Tyler Fleming Cloutier &lt;cloutiertyler-AT-aol.com&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; I would, personally, be very careful about discarding the mathematical<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; terms since they are so widely used and understood.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; IMO it&#39;s better to leave them aside than to use them in “creative” ways<br>
&gt;&gt;&gt;&gt;&gt;&gt; that might be misleading.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Agreed. I’m all for that.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; One issue is that it’s going to be hard to search for the operation I<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; want considering I won’t be looking for &quot;func<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; invertingMembershipOfContentsOf(other: Self) -&gt; Self”. I’m concerned<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; people are going to have to do mental gymnastics to build the map from<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; math term to Swift function every time they want to look for a set<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; operation method. “func invertingMembershipOfContentsOf(other: Self)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; -&gt; Self” doesn’t exactly seem to fit in the commonly held Venn diagram<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; mental model of set operations. You could always have a documentation<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; comment that specifies the mathematical term so that people didn’t<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; have to double check themselves every time.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; That being said, if the autocomplete issue is not a concern, I’m of<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; the opinion that the names Ricardo proposed are short, clear, and are<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; not so hard to fit to my Venn diagram mental model.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; +1<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; However, I tend to think that if there has to be this much dancing to<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; name a set of fundamental operations, the guidelines aren’t<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; accomplishing their goal.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; I can&#39;t disagree.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; It’s going to make it that much harder for people do design their own<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; APIs. I&#39;m having quite a time trying to conform Mattt’s Surge API to<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; the guidelines.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; Please explain in detail.  Without details we don&#39;t know what&#39;s wrong<br>
&gt;&gt;&gt;&gt;&gt;&gt; with the guidelines.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Ah, I apologize. I’ve gone into detail about this API on the list<br>
&gt;&gt;&gt;&gt;&gt; before, but I should have included the details here.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Here are my previous posts:<br>
&gt;&gt;&gt;&gt;&gt; <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160118/007560.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160118/007560.html</a><br>
&gt;&gt;&gt;&gt;&gt; &lt;<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160118/007560.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160118/007560.html</a>&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Basically the issues come down to the following. The Accelerate<br>
&gt;&gt;&gt;&gt;&gt; framework typical operates in a non-mutating way. This means that my<br>
&gt;&gt;&gt;&gt;&gt; API only has non mutating member functions and I should use the ed/ing<br>
&gt;&gt;&gt;&gt;&gt; rule according to the guidelines to name my methods.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; This is very difficult for some methods. I’m able to frequently get<br>
&gt;&gt;&gt;&gt;&gt; around the problem for things like “sin” or “arctan” by keeping them<br>
&gt;&gt;&gt;&gt;&gt; as global functions, but I can’t do that for a number of<br>
&gt;&gt;&gt;&gt;&gt; methods. Consider:<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; remainder<br>
&gt;&gt;&gt;&gt;&gt; dot (returns a scalar, thus there can’t be a mutating version, so<br>
&gt;&gt;&gt;&gt;&gt; should I just call it dot? Guidelines don’t really comment on this)<br>
&gt;&gt;&gt;&gt;&gt; mean (same as above)<br>
&gt;&gt;&gt;&gt;&gt; cross<br>
&gt;&gt;&gt;&gt;&gt; reciprocal<br>
&gt;&gt;&gt;&gt;&gt; threshold<br>
&gt;&gt;&gt;&gt;&gt; copysign<br>
&gt;&gt;&gt;&gt;&gt; fastFourierTransform<br>
&gt;&gt;&gt;&gt;&gt; pow (arguably the method version should be called raisedTo)<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; I could force all these to be global functions only, but these are not<br>
&gt;&gt;&gt;&gt;&gt; as cut and dry as “sin” or “arctan”. I feel like I’d be splitting my<br>
&gt;&gt;&gt;&gt;&gt; API up into two parts just based on the fact that it’s difficult to<br>
&gt;&gt;&gt;&gt;&gt; use the ed/ing rule. That makes it very difficult for users to find<br>
&gt;&gt;&gt;&gt;&gt; certain functions in my API.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; In this case there are no corresponding mutating operations because of<br>
&gt;&gt;&gt;&gt;&gt; the way Accelerate works, but one could certainly imagine an API with<br>
&gt;&gt;&gt;&gt;&gt; mutating counterparts. The way I read the guidelines, they seem to<br>
&gt;&gt;&gt;&gt;&gt; imply I should use ed/ing regardless of whether there is a mutating<br>
&gt;&gt;&gt;&gt;&gt; counterpart. I’d love to hear your thoughts on this.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; As long as the ones without side effects read as noun phrases and the<br>
&gt;&gt;&gt;&gt; ones with side-effects read as verb phrases, you&#39;re good.  No ed/ing<br>
&gt;&gt;&gt;&gt; needed.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Ah yes, you are very right. Still what would the mutating versions<br>
&gt;&gt;&gt; of remainder, fastFourierTransform, or reciprocal be? getRemainder?<br>
&gt;&gt;&gt; applyFastFourierTransform? reciprocate? I suppose those aren’t so<br>
&gt;&gt;&gt; bad.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I also suppose cross could become x.crossProduct(with: y) and<br>
&gt;&gt;&gt; copysign, x.copyingSign(of: y). Seems a little verbose, but it does<br>
&gt;&gt;&gt; the job.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Thanks,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Tyler<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Thanks,<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Tyler<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; Tyler<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; On Feb 13, 2016, at 9:09 PM, Ricardo Parada via<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; swift-evolution<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Hi Dave,<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; I would be okay with staying away from the mathematical terms<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; similar to what you are suggesting except that the union can still<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; be made more concise if you use merged / merge for the base name and<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; shorten the labels to a bare minimum without loosing clarity.  In<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; addition, the merge can have a second parameter with a default to<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; false in order to implement the symmetric difference<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; (a.k.a. exclusive or).  Recall that symmetric difference is the<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; union of two sets and then removing the intersection (or members in<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; common).  I think it looks perfect (concise and clear).  What does<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; everybody else think?<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Non-mutable<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; let union =                    a.merged(with: b)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; let intersection =             a.members(in: b)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; let difference =               a.removingMembers(in: b)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; let symmetricDifference =      a.merged(with: b, removingMembersInCommon: true)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Mutable (In-Place)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; a.merge(with: b)               // union in-place<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; a.removeMembers(notIn: b)      // intersect in-place<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; a.removeMembers(in: b)         // difference in-place<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; a.merge(with: b, removeMembersInCommon: true)  // symmetric difference in-place<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Ricardo Parada<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; On Feb 13, 2016, at 1:16 PM, Dave Abrahams via swift-evolution<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; on Fri Feb 12 2016, Ricardo Parada &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Hi all,<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; I can’t make up my mind.  Let me propose two different alternatives<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; that I’m not sure if they have been considered:<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; ALTERNATIVE 1<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Non-mutable (noun-based)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; -  func union(other: Self) -&gt; Self<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; +  func union(other: Self) -&gt; Self           Assumes union is a noun, i.e. not a verb<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; -  func intersect(other: Self) -&gt; Self<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; +  func intersection(other: Self) -&gt; Self<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; -  func subtract(other: Self) -&gt; Self<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; +  func subtraction(other: Self) -&gt; Self<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; -  func exclusiveOr(other: Self) -&gt; Self<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; +  func symmetricSubtraction(other: Self) -&gt; Self<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Mutable (verb-based)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; -  mutating func unionInPlace(other: Self)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; +  mutating func unite(other: Self)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; -  mutating func intersectInPlace(other: Self)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; +  mutating func intersect(other: Self)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; -  mutating func subtractInPlace(other: Self)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; +  mutating func subtract(other: Self)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; -  mutating func exclusiveOrInPlace(other: Self)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; +  mutating func symmetricSubtract(other: Self)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Comments:<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; With this alternative we keep the union name which I assume is<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; popular.  However, one has to accept unite as a verb (for the mutable<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; version) as I wanted all the mutable methods use verbs for<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; consistency.  I think unite is acceptable because it can be found in<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; the dictionary and it is a verb.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Notice that all the non-mutable methods use nouns: union,<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; intersection, subtraction and symmetricSubtraction.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; I understand some may oppose to symmetricSubtraction saying that<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; symmetricSubraction is not as common as &quot;exclusive or&quot;.  However,<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; using symmetricSubtraction is consistent with subtraction and it hints<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; to a variation of the “subtraction&quot; operation.  We will get used to it<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; quickly / easily.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; The mutable methods all use verbs:  unite, intersect, subtract and symmetricSubtract.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; ALTERNATIVE 2<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Non-mutable<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; -  func union(other: Self) -&gt; Self<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; +  func adding(other: Self) -&gt; Self<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; -  func intersect(other: Self) -&gt; Self<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; +  func intersecting(other: Self) -&gt; Self<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; -  func exclusiveOr(other: Self) -&gt; Self<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; +  func exclusiveOring(other: Self) -&gt; Self<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; -  func subtract(other: Self) -&gt; Self<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; +  func removing(other: Self) -&gt; Self<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Mutable<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; -  mutating func unionInPlace(other: Self)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; +  mutating func add(other: Self)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; -  mutating func intersectInPlace(other: Self)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; +  mutating func intersect(other: Self)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; -  mutating func exclusiveOrInPlace(other: Self)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; +  mutating func exclusiveOr(other: Self)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; -  mutating func subtractInPlace(other: Self)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; +  mutating func remove(other: Self)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Comments: This alternative gives up on union in favor or add.  Many<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; may not like this, that is why I have it as the second alternative.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; It brings back exclusiveOr and treats it as a verb.  Some may argue<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; that exclusiveOr is a noun for the &quot;exclusive or&quot; operation.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; If we are going to force Set fit the naming guidelines, I would prefer<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; to stay away from the mathematical terms altogether.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; func insertingContentsOf(other: Self) -&gt; Self                 // union<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; mutating func insertContentsOf(other)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; func members(in other: Self) -&gt; Self                           // intersection<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; mutating func removeMembers(notIn: other)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; func removingMembersAndAddingNonMembers(in other: Self) -&gt; Self // symmetric difference<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; mutating func removeMembersAndAddingNonMembers(in other: Self)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; func removingMembers(in other: Self) -&gt; Self                    // subtract<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; mutating func removeMembers(in other: Self)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; If it would help with clarity, we could replace &quot;in&quot; with &quot;foundIn&quot;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; above.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; --<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; -Dave<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; swift-evolution mailing list<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; &lt;mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; &lt;<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a>&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; swift-evolution mailing list<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; --<br>
&gt;&gt;&gt;&gt;&gt;&gt; -Dave<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; --<br>
&gt;&gt;&gt;&gt; -Dave<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; swift-evolution mailing list<br>
&gt;&gt;&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt;&gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; swift-evolution mailing list<br>
&gt;&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt; _______________________________________________<br>
&gt; swift-evolution mailing list<br>
&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt; <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>
-Dave<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>
</blockquote></div>