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