<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=""><div style="margin: 0px;" class=""><span style="color: rgb(112, 61, 170); font-family: Menlo; font-size: 11px;" class=""><span style="color: rgb(0, 0, 0); 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><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="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></body></html>