[swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[J.E. Schotsman]

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161020/b4e36dac/attachment.html>