For the Arithmetic protocol how about changing it to: protocol Arithmetic { func + (lhs: Self, rhs: Self) -> Self mutating func += (rhs: Self) -> Self ... }
That way naming issues are largely avoided, except for `mutating func negate()` which has no operator and would therefore have to be a normal, non-operator, func. On Saturday, 16 April 2016, Nicola Salmoria via swift-evolution < swift-evolution@swift.org> wrote: > > Oh, a couple more things I just thought of: > > > > > public protocol Arithmetic: Equatable, IntegerLiteralConvertible { > > If your goals include supporting complex numbers, how is > IntegerLiteralConvertible going to fit in there? > > > > > /// Initialize to zero > > > init() > > 0 is valuable as the additive identity. Should there also be a way to > get 1, the multiplicative identity? If you need both, should these be > static properties instead of initializers? > > Interestingly, these two questions are related. > > If you expose the multiplicative identity, you automatically expose a > natural way to convert from an integer N: just add `one` to itself N times. > If N is negative, take the opposite. > > For complex numbers the multiplicative identity is 1 + 0i, so this means > that Complex(N) = N + 0i. > > As an aside, a default generic implementation of IntegerLiteralConvertible > would run in O(log N) steps, using the “double-and-add” algorithm: > > https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplication#Double-and-add > . > Though I don’t think this is particularly useful for our use case :-) > > — > Nicola > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <javascript:;> > https://lists.swift.org/mailman/listinfo/swift-evolution > -- -- Howard.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution