However, it's specifically the set algebra operators that I have the
greatest objection to cherrypicking:
* Each of these operators has a specific meaning; it is an anti-goal to
support repurposing the union operator for any other purpose than forming a
union of two sets, for instance.
* Thus, the only rationale for inclusion of these operators is to support
aliasing the set algebra protocol members.
That’s called customization and I don’t see what’s wrong with that.
I bet a sizeable number of developers want the set operators and they should be able to custom-define them.
* Now, if it is appropriate for these set algebra operations to be
accessible through these operators, then the standard library should be
* However, exactly such an API has been trialled on a Swift branch, and the
set algebra renaming debate of 2015 (or was it early 2016?) on this very
list resulted in a renaming that *rejected* the use of these operators.
* Given that these operators have been deemed not appropriate for the only
methods that should use them, we should *not* specifically enable these
symbols as valid operator characters.
If it had been decided to provide the operators, which would it have been: the bitwise operator symbols or the mathematical set operation symbols?
That dilemma alone is enough reason to leave this as a customization point, IMHO.
The sheer length of the great Set API renaming thread itself makes clear this is a linguistic pain zone which is avoided entirely with the operator symbols which are very clear and concise.
One reason for the difficulty to arrive at good English names for the methods was the matter of type method vs instance method.
For example, x.formUnionWith(y: Element) vs Set.formUnion(of x: Element, and y: Element)
Basically the non-mutating methods feel like type methods but the mutating ones must be instance methods.
This largely academic difference too is avoided with the operator approach.
On 19 Oct 2016, at 19:00,Xiaodi Wu wrote: