[swift-evolution] ed/ing, InPlace, Set/SetAlgebra naming resolution

Dave Abrahams dabrahams at apple.com
Mon Feb 15 15:15:27 CST 2016 

on Mon Feb 15 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:

> 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"!
>
> 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.

I understand; thanks for your patience.

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

-- 
-Dave

More information about the swift-evolution mailing list