<div dir="ltr">Thanks for working on getting an answer for this. I'm sure there's a perfectly good justification for excluding 'inPlace', but based on all the conversations about naming that I've been trying (with mixed success) to follow, it seems like none of the alternatives are all that palatable:<div><br></div><div>- 'inPlace' exception - superficially a good solution, but there's a reason we can't use it</div><div>- Applying standard rules to terms of art - leads to ugly, non-standard (both in terms of terminology and general English usage) terminology<br><div>- Moving away from math naming to get rid of terms of art - avoids the 'most obvious' name for the thing, privileges a specific use case (UI/app programming) over the general domain (sets as a mathematical concept)</div><div><br></div><div>Anyways, I'll wait for more information before making any further judgments.</div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 15, 2016 at 1:15 PM, Dave Abrahams via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
on Mon Feb 15 2016, Xiaodi Wu <<a href="http://xiaodi.wu-AT-gmail.com" rel="noreferrer" target="_blank">xiaodi.wu-AT-gmail.com</a>> wrote:<br>
<br>
> On that topic, you mentioned earlier that you've asked someone involved in<br>
> the decision to explain why we can't have a term-of-art InPlace exception.<br>
> That would be enormously beneficial as it seems we've returned once again<br>
> to: "InPlace isn't so bad"!<br>
><br>
> It's difficult to advance alternatives clearly superior to InPlace while<br>
> the objection to its use in this context originating from the Inner Sanctum<br>
> of Swiftiness[TM] remains opaque.<br>
<br>
</span>I understand; thanks for your patience.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
><br>
> On Mon, Feb 15, 2016 at 2:32 PM Dave Abrahams via swift-evolution <<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
>><br>
>> on Mon Feb 15 2016, Austin Zheng <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> > +1. Would rather see us retain the (IMHO) correct math-based<br>
>> 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">swift-evolution@swift.org</a>> wrote:<br>
>> ><br>
>> >> It pains me that well-known math terms and even whole protocols get<br>
>> 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<br>
>> terms<br>
>> >> of art. These describe for the most part functions for which there are<br>
>> 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<br>
>> 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<br>
>> a<br>
>> >> SetAlgebra protocol if it can ensure these functions exist for<br>
>> 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">swift-evolution@swift.org</a>> wrote:<br>
>> >><br>
>> >>><br>
>> >>> on Mon Feb 15 2016, Xiaodi Wu <<a href="mailto:swift-evolution@swift.org">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>
>> >>><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">swift-evolution@swift.org</a>> wrote:<br>
>> >>> ><br>
>> >>> >><br>
>> >>> >> on Mon Feb 15 2016, Maximilian Hünenberger <<br>
>> <a href="mailto:swift-evolution@swift.org">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<br>
>> the<br>
>> >>> >> domain of building GUI apps is more important than that of math, so<br>
>> the<br>
>> >>> >> look and feel of sets should match those of most other (non-math)<br>
>> APIs.<br>
>> >>> >><br>
>> >>> >> > Since these terms almost always return a new instance we should<br>
>> 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">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<br>
>> for<br>
>> >>> >> >> trigonometric functions, etc. Nor can you really 'cross<br>
>> produce'...<br>
>> >>> >> >><br>
>> >>> >> >> So consistent is this trend that where two words might be<br>
>> 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<br>
>> 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<br>
>> 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<br>
>> all<br>
>> >>> >> >> proposed solutions so far come down to one of four options,<br>
>> either<br>
>> >>> >> >> applied globally or only to sets for now, punting the rest down<br>
>> 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<br>
>> is<br>
>> >>> >> >> even a possibility. (3) has elicited a lot of discussion and<br>
>> >>> >> >> visceral reactions. (4) might be workable for sets alone but<br>
>> surely<br>
>> >>> >> >> can't be a generalized solution for all mathematical concepts to<br>
>> 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">swift-evolution@swift.org</a>> wrote:<br>
>> >>> >> >>>> On Feb 14, 2016, at 12:48 PM, Dave Abrahams<br>
>> >>> >> >>>> <<a href="mailto:dabrahams@apple.com">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">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<br>
>> the<br>
>> >>> map<br>
>> >>> >> from<br>
>> >>> >> >>>>>>> math term to Swift function every time they want to look<br>
>> for a<br>
>> >>> set<br>
>> >>> >> >>>>>>> operation method. “func<br>
>> invertingMembershipOfContentsOf(other:<br>
>> >>> >> Self)<br>
>> >>> >> >>>>>>> -> Self” doesn’t exactly seem to fit in the commonly held<br>
>> 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,<br>
>> 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<br>
>> Surge<br>
>> >>> API<br>
>> >>> >> to<br>
>> >>> >> >>>>>>> the guidelines.<br>
>> >>> >> >>>>>><br>
>> >>> >> >>>>>> Please explain in detail. Without details we don't know<br>
>> what's<br>
>> >>> >> wrong<br>
>> >>> >> >>>>>> with the guidelines.<br>
>> >>> >> >>>>><br>
>> >>> >> >>>>> Ah, I apologize. I’ve gone into detail about this API on the<br>
>> list<br>
>> >>> >> >>>>> before, but I should have included the details here.<br>
>> >>> >> >>>>><br>
>> >>> >> >>>>> Here are my previous posts:<br>
>> >>> >> >>>>><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>
>> >>><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<br>
>> 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<br>
>> 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<br>
>> frequently<br>
>> >>> get<br>
>> >>> >> >>>>> around the problem for things like “sin” or “arctan” by<br>
>> 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<br>
>> 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<br>
>> 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<br>
>> API<br>
>> >>> with<br>
>> >>> >> >>>>> mutating counterparts. The way I read the guidelines, they<br>
>> 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<br>
>> 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<br>
>> versions<br>
>> >>> >> >>> of remainder, fastFourierTransform, or reciprocal be?<br>
>> getRemainder?<br>
>> >>> >> >>> applyFastFourierTransform? reciprocate? I suppose those aren’t<br>
>> 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<br>
>> 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">swift-evolution@swift.org</a>><br>
>> >>> >> >>>>>>>> wrote:<br>
>> >>> >> >>>>>>>><br>
>> >>> >> >>>>>>>> Hi Dave,<br>
>> >>> >> >>>>>>>><br>
>> >>> >> >>>>>>>> I would be okay with staying away from the mathematical<br>
>> terms<br>
>> >>> >> >>>>>>>> similar to what you are suggesting except that the union<br>
>> 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).<br>
>> 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">swift-evolution@swift.org</a><br>
>> >>> >> >>>>>>>>> <mailto:<a href="mailto:swift-evolution@swift.org">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">swift-evolution@swift.org</a><br>
>> >>> >> >>>>>>>>> <mailto:<a href="mailto:swift-evolution@swift.org">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<br>
>> 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<br>
>> 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<br>
>> for<br>
>> >>> >> >>>>>>>>>> consistency. I think unite is acceptable because it can<br>
>> 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<br>
>> 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<br>
>> 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"<br>
>> 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">swift-evolution@swift.org</a><br>
>> >>> >> >>>>>>>>> <mailto:<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>
>> >>> >> >>>>>>>>> <<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">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">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">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">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">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">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">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">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">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">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>
-Dave<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>
</div></div></blockquote></div><br></div>