[Proposal] Refining Identifier and Operator Symbology


(J.E. Schotsman) #1

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.

···

On 19 Oct 2016, at 19:00,Xiaodi Wu wrote:


(Xiaodi Wu) #2

I'm sympathetic to the arguments you raise here. However, they were brought
up during the SetAlgebra API discussion and rejected in favor of the
current API. Now is not the time to re-litigate that thread.

The point I'm making is that it's all right if Swift's operators happen to
support the mathematical set operators, but specifically adding them
because people disagree with the direction of Swift is a non-goal or
anti-goal.

···

On Thu, Oct 20, 2016 at 04:23 J.E. Schotsman via swift-evolution < swift-evolution@swift.org> wrote:

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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution