> On 19 Oct 2016, at 19:00,Xiaodi Wu wrote:
>
> 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
> providing them.
>
> * 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.
Jan E.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
