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