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