<div style="white-space:pre-wrap">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 important for Swift than math.<br><br>Problem is, the moment you name something SetAlgebra, you've set user expectations that it's a 'math API'. Those ain't UI terms.<br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 15, 2016 at 11:25 AM Dave Abrahams via swift-evolution <<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, Maximilian Hünenberger <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
<br>
> I also prefer (2). Isn't "union", "intersection", ... a "Term of 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 math 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 <cloutiertyler-AT-aol.com> 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 <cloutiertyler-AT-aol.com> wrote:<br>
>>>>>><br>
>>>>>>> I would, personally, be very careful about discarding the 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 “creative” 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 operation I<br>
>>>>>>> want considering I won’t be looking for "func<br>
>>>>>>> invertingMembershipOfContentsOf(other: Self) -> Self”. I’m concerned<br>
>>>>>>> people are going to have to do mental gymnastics to build the map from<br>
>>>>>>> math term to Swift function every time they want to look for a set<br>
>>>>>>> operation method. “func invertingMembershipOfContentsOf(other: Self)<br>
>>>>>>> -> Self” doesn’t exactly seem to fit in the commonly held Venn diagram<br>
>>>>>>> mental model of set operations. You could always have a documentation<br>
>>>>>>> comment that specifies the mathematical term so that people didn’t<br>
>>>>>>> have to double check themselves every time.<br>
>>>>>>><br>
>>>>>>> That being said, if the autocomplete issue is not a concern, I’m of<br>
>>>>>>> the opinion that the names Ricardo proposed are short, clear, and 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 dancing 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 their own<br>
>>>>>>> APIs. I'm having quite a time trying to conform Mattt’s Surge API to<br>
>>>>>>> the guidelines.<br>
>>>>>><br>
>>>>>> Please explain in detail. Without details we don't know what's 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>
>>>>> <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>
>>>>> <<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>
>>>>> Basically the issues come down to the following. The Accelerate<br>
>>>>> framework typical operates in a non-mutating way. This means that my<br>
>>>>> API only has non mutating member functions and I should use the 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 get<br>
>>>>> around the problem for things like “sin” or “arctan” by keeping 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 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 are not<br>
>>>>> as cut and dry as “sin” or “arctan”. I feel like I’d be splitting my<br>
>>>>> API up into two parts just based on the fact that it’s difficult to<br>
>>>>> use the ed/ing rule. That makes it very difficult for users to find<br>
>>>>> certain functions in my API.<br>
>>>>><br>
>>>>> In this case there are no corresponding mutating operations because of<br>
>>>>> the way Accelerate works, but one could certainly imagine an API with<br>
>>>>> mutating counterparts. The way I read the guidelines, they seem to<br>
>>>>> imply I should use ed/ing regardless of whether there is a 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 the<br>
>>>> ones with side-effects read as verb phrases, you're good. No 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 still<br>
>>>>>>>> be made more concise if you use merged / merge for the base name and<br>
>>>>>>>> shorten the labels to a bare minimum without loosing clarity. In<br>
>>>>>>>> addition, the merge can have a second parameter with a default to<br>
>>>>>>>> false in order to implement the symmetric difference<br>
>>>>>>>> (a.k.a. exclusive or). Recall that symmetric difference is the<br>
>>>>>>>> union of two sets and then removing the intersection (or members in<br>
>>>>>>>> common). I think it looks perfect (concise and clear). What 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, 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 difference in-place<br>
>>>>>>>><br>
>>>>>>>> Ricardo Parada<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>>> On Feb 13, 2016, at 1:16 PM, Dave Abrahams via 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 <<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 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 is a 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 is<br>
>>>>>>>>>> popular. However, one has to accept unite as a verb (for the mutable<br>
>>>>>>>>>> version) as I wanted all the mutable methods use verbs for<br>
>>>>>>>>>> consistency. I think unite is acceptable because it can be 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 that<br>
>>>>>>>>>> symmetricSubraction is not as common as "exclusive or". However,<br>
>>>>>>>>>> using symmetricSubtraction is consistent with subtraction and it hints<br>
>>>>>>>>>> to a variation of the “subtraction" operation. We will get used to it<br>
>>>>>>>>>> quickly / easily.<br>
>>>>>>>>>><br>
>>>>>>>>>> The mutable methods all use verbs: unite, intersect, subtract 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 add. Many<br>
>>>>>>>>>> may not like this, that is why I have it as the second alternative.<br>
>>>>>>>>>> It brings back exclusiveOr and treats it as a verb. Some may 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 would prefer<br>
>>>>>>>>> to stay away from the mathematical terms altogether.<br>
>>>>>>>>><br>
>>>>>>>>> func insertingContentsOf(other: Self) -> Self // union<br>
>>>>>>>>> mutating func insertContentsOf(other)<br>
>>>>>>>>><br>
>>>>>>>>> func members(in other: Self) -> Self // intersection<br>
>>>>>>>>> mutating func removeMembers(notIn: other)<br>
>>>>>>>>><br>
>>>>>>>>> func removingMembersAndAddingNonMembers(in other: Self) -> Self // symmetric difference<br>
>>>>>>>>> mutating func removeMembersAndAddingNonMembers(in other: Self)<br>
>>>>>>>>><br>
>>>>>>>>> func removingMembers(in other: Self) -> Self // subtract<br>
>>>>>>>>> mutating func removeMembers(in other: Self)<br>
>>>>>>>>><br>
>>>>>>>>> If it would help with clarity, we could replace "in" with "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>
</blockquote></div>