[swift-evolution] protocol-oriented integers (take 2)

[Stephen Canon]

Responding to the thread in general here, not so much any specific email:

“Arithmetic” at present is not a mathematically-precise concept, and it may be a mistake to make it be one[1]; it’s a mathematically-slightly-fuzzy “number” protocol. FWIW, if I had to pick a mathematical object to pin it to, I would make it a [non-commutative] ring, which give it:

	addition, subtraction, multiplication, IntegerLiteralConvertible, and an inverse: T? property.

Note that this would make division go out the window, but we would *preserve* int literal convertible (because there’s a unique map from Z to any ring — Z is the initial object in the category of rings). I think that it’s quite important to keep that for writing generic code.

Vectors and points are not “numbery” in this sense, so they should not conform to this protocol, which is why it’s OK that multiplication and int literals don’t make sense for them. They’re property a vector space or module built over a scalar type.

I would be OK with moving division out of the Arithmetic protocol, as the division operator is fundamentally different for integers and floating-point, and you want to have separate left- and right- division for quaternions and matrices. I would be pretty strongly opposed to removing integer literals; they rightfully belong here.

I think the name “Arithmetic” is sound. It is deliberately *not* one of the standard mathematical abstractions, reserving those names for folks who want to build a precise lattice of algebraic objects. Vectors don’t belong in this protocol, though.

– Steve

[1] We don’t want to make a semester course in modern algebra a prerequisite to using Swift, as much as I would enjoy building a tower of formalism as a mathematician.