<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=""><div class="">My vocabulary is probably not precise (and please correct me if so), but:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">a.members(in: b)</font></div><div class=""><font face="Menlo" class="">a.members(notIn: b)</font></div><div class=""><br class=""></div><div class="">Are both overrides in my original message, because they use the same base name before the parentheses. I know that argument labels are part of the function signature. I was just trying to say that I find the code above more consistent because the mutating versions also share the same base name:</div><div class=""><br class=""></div><div class=""><span style="font-family: Menlo;" class="">a.removeMembers(notIn: b)</span><br style="font-family: Menlo;" class=""><span style="font-family: Menlo;" class="">a.removeMembers(in: b)</span></div><br class=""><div><blockquote type="cite" class=""><div class="">On 14 Feb 2016, at 17:39, Dave Abrahams 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=""><div class=""><br class="">on Sun Feb 14 2016, David Hart <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">I don’t really agree with Dave’s comments about removing ‘with', <br class=""></blockquote><br class="">When one road merges with another, both are changed.<br class=""><br class=""><blockquote type="cite" class="">but here’s one of mine – making the non-mutating difference an<br class="">override of intersection because it sounds clearer to me and is<br class="">consistent with the mutable versions being overrides:<br class=""></blockquote><br class="">I don't see any overrides around here. Care to clarify?<br class=""><br class=""><blockquote type="cite" 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.members(notIn: b)<br class="">let symmetricDifference = a.merged(with: b, 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)<span class="Apple-tab-span" style="white-space:pre"> </span>// difference in-place<br class="">a.merge(with: b, removingMembersInCommon: true) // symmetric difference in-place<br class=""><br class=""><blockquote type="cite" class="">On 14 Feb 2016, at 17:10, Dave Abrahams via swift-evolution<br class=""><<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><br class="">on Sat Feb 13 2016, Ricardo Parada <<a href="http://rparada-at-mac.com" class="">rparada-AT-mac.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">Hi Dave,<br class=""><br class="">I would be okay with staying away from the mathematical terms similar<br class="">to what you are suggesting except that the union can still be made<br class="">more concise if you use merged / merge for the base name and shorten<br class="">the labels to a bare minimum without loosing clarity. In addition,<br class="">the merge can have a second parameter with a default to false in order<br class="">to implement the symmetric difference (a.k.a. exclusive or). Recall<br class="">that symmetric difference is the union of two sets and then removing<br class="">the intersection (or members in common). I think it looks perfect<br class="">(concise and clear). What does everybody else think?<br class=""><br class="">Non-mutable<br class=""><br class="">let union = <span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>a.merged(with: b)<br class="">let intersection = <span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>a.members(in: b)<br class="">let difference = <span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>a.removingMembers(in: b)<br class="">let symmetricDifference = <span class="Apple-tab-span" style="white-space:pre"> </span>a.merged(with: b, removingMembersInCommon: true)<br class=""><br class="">Mutable (In-Place)<br class=""><br class="">a.merge(with: b)<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>// union in-place<br class="">a.removeMembers(notIn: b)<span class="Apple-tab-span" style="white-space:pre"> </span>// intersect in-place<br class="">a.removeMembers(in: b)<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>// difference in-place<br class="">a.merge(with: b, removeMembersInCommon: true)<span class="Apple-tab-span" style="white-space:pre"> </span>// symmetric difference in-place<br class=""></blockquote><br class="">I love your changes to my suggestion, Ricardo! The minor alterations I<br class="">would make are:<br class=""><br class="">1. In both cases the Bool parameter ought to be called<br class=""> “removingMembersInCommon”<br class=""><br class="">2. I would remove “with” from the in-place merge operation. We're<br class=""> really asking the receiver to merge b into itself. “With” gives it<br class=""> the sense that it might almost be mutating b.<br class=""><br class=""><blockquote type="cite" class="">Ricardo Parada<br class=""><br class=""><blockquote type="cite" class="">On Feb 13, 2016, at 1:16 PM, Dave Abrahams via swift-evolution<br class=""><<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><br class="">on Fri Feb 12 2016, Ricardo Parada <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>>> wrote:<br class=""><br class=""><blockquote type="cite" class="">Hi all,<br class=""><br class="">I can’t make up my mind. Let me propose two different 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<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>Assumes union is a 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 is<br class="">popular. However, one has to accept unite as a verb (for the 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 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 that<br class="">symmetricSubraction is not as common as "exclusive or". However,<br class="">using symmetricSubtraction is consistent with subtraction and it hints<br class="">to a variation of the “subtraction" operation. We will get used to it<br class="">quickly / easily.<br class=""><br class="">The mutable methods all use verbs: unite, intersect, subtract 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 add. Many<br class="">may not like this, that is why I have it as the second alternative.<br class="">It brings back exclusiveOr and treats it as a verb. Some may argue<br class="">that exclusiveOr is a noun for the "exclusive or" operation.<br class=""></blockquote><br class="">If we are going to force Set fit the naming guidelines, I would prefer<br class="">to stay away from the mathematical terms altogether.<br class=""><br class=""> func insertingContentsOf(other: Self) -> Self // union<br class=""> mutating func insertContentsOf(other)<br class=""><br class=""> func members(in other: Self) -> Self // intersection<br class=""> mutating func removeMembers(notIn: other)<br class=""><br class=""> func removingMembersAndAddingNonMembers(in other: Self) -> Self // symmetric difference<br class=""> mutating func removeMembersAndAddingNonMembers(in other: Self)<br class=""><br class=""> func removingMembers(in other: Self) -> Self // subtract<br class=""> mutating func removeMembers(in other: Self)<br class=""><br class="">If it would help with clarity, we could replace "in" with "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" class="">swift-evolution@swift.org</a><br class=""><mailto:swift-evolution@swift.org><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""><https://lists.swift.org/mailman/listinfo/swift-evolution><br class=""></blockquote></blockquote><br class="">-- <br class="">-Dave<br class="">_______________________________________________<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=""></blockquote><br class="">_______________________________________________<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=""></blockquote><br class="">-- <br class="">-Dave<br class=""><br class="">_______________________________________________<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></div></blockquote></div><br class=""></body></html>