<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I also am greatly in favor of set algebra using infix and assignment operators. As already mentioned, this removes ambiguity about mutating or not mutating. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">In addition, I believe this is not an abuse of operators such that they become confusing: all of the operators are familiar from other uses. Furthermore, I feel this adds consistency mathematically with the rest of the language: all of the major algebras (integers, reals, booleans) and now sets would have similar syntax and "feel".<br><br>Then again, I might have an excessive preference for mathematical constructs in Swift to come out "cute", which isn't necessarily the goal of Swift.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Just my 2 cents,</div><div id="AppleMailSignature"><br><div>Donald Pinckney</div></div><div><br>On Feb 12, 2016, at 2:33 PM, Craig Cruden via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">I like the set operators being “operator” infix symbols - and would be happy with those. <div class=""><br class=""></div><div class="">Definitely far better than some of the programmer assaults on the english language so far :p</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 2016-02-13, at 5:30:20, Sébastien Blondiau 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div style="margin: 0px;" class=""><span style="color: rgb(112, 61, 170); font-family: Menlo; font-size: 11px;" class=""><span style="font-family: Helvetica; font-size: 12px;" class="">Using only the operators </span>| & - ^ |= &= -= ^= </span>for the operations on Set would simplify the code and resolve the problem of the names of these functions. Set do not really need these functions as method, only the operators would be enough, like the<font color="#703daa" class=""> </font><span style="color: rgb(112, 61, 170); font-family: Menlo; font-size: 11px;" class="">BitwiseOperationsType </span>which do not have the methods <span style="color: rgb(112, 61, 170); font-family: Menlo; font-size: 11px;" class="">xor and orInPlace ...</span></div></div><div class=""><br class=""></div><div class="">With the operators, the question of "does this function mutate?" would not be anymore. The code would get clarity and brevity without problem of naming. Isn’t that the API Design Guidelines?</div><div class=""><br class=""></div><div class="">--</div><div class="">Sébastien</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 12 févr. 2016 à 00:24, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">The API guidelines working group took up the issue of the InPlace suffix<br class="">yesterday, and decided that it was not to be used anywhere in the<br class="">standard library. We are planning to apply the changes shown here<br class=""><<a href="https://gist.github.com/dabrahams/d872556291a3cb797bd5" class="">https://gist.github.com/dabrahams/d872556291a3cb797bd5</a>> to the API of<br class="">SetAlgebra (and consequently Set) to make it conform to the guidelines<br class="">under development.<br class=""></blockquote><br class="">My suggestions:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>union -> union<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>intersect -> intersection<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>subtract -> subtraction<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>unionInPlace -> unite<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>intersectInPlace -> intersect<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>subtractInPlace -> subtract<br class=""><br class="">In other words, treat the mutating forms as imperative verbs and the nonmutating forms as nouns. This basically makes the nonmutating forms into accessors, which I think is a good alternative given the trouble we're having with -ing/-ed.<br class=""><br class="">That still leaves exclusiveOr, which is frankly a horrible name to begin with. I think we have to derive a name from the "symmetric difference" terminology, giving us<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>exclusiveOr -> difference<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>exclusiveOrInPlace -> differ<br class=""><br class="">However, given the difficulty we're having coming up with names, we might want to explore using operators instead.<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>union -> |<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>intersect -> &<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>subtract -> -<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>exclusiveOr -> ^<br class=""><br class="">This gives us extremely straightforward mutating operators, of course, since we do have a convention for in-place operators:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>unionInPlace -> |=<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>intersectInPlace -> &=<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>subtract -> -=<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>exclusiveOr -> ^=<br class=""><br class="">Some things to like about these operators:<br class=""><br class="">* They are not used for anything on sequences or collections, so they don't overload existing concepts like concatenation with incompatible semantics.<br class="">* They have the same commutativity and transitivity as the associated integer operations.<br class="">* The bitwise forms of `|` and `&` are already documented (in `_DisallowMixedSignArithmetic`) as the union and intersection of the bits, and `^` is documented in a compatible way. Meanwhile, `-` literally means "subtraction", the exact same operation we're exposing.<br class="">* And of course, it's just *nice* to not have to write long, unwieldy method names for fundamental operations.<br class=""><br class="">Swift generally tries not to overload operators too much, but I think in this case, these overloads would be appropriate and helpful, while also getting us out of a sticky naming problem.<br class=""><br class="">-- <br class="">Brent Royal-Gordon<br class="">Architechies<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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>