This is a really key point to make. I would refer everyone to some of my favorite sequences: the number of semigroups that can be defined on a set of order n and the number of groups. Note that for any non-trivial set, the number of such structures is staggeringly huge. It doesn't suffice to have just "additive" and "multiplicative" groups; it doesn't suffice to have any finite named set of group operations. Even if we restrict ourselves to familiar operations, the integers are also a semigroup under |, ^, &, min, max, ...
This is a big part of the reason why I personally haven't pursued adding protocols like Semigroup, Group, or Ring to the standard library. You really want to be able to say that a type together with operations conforms to these mathematical structures, rather than saying that the type does with a fixed operation. You should be able to say that (Int, +, 0) is a semi-group, but also that (Int, *, 1) is and (Int, |, 0) is. In order for these "protocols" to be useful for generic programming, you really need to be able to have a set conform repeatedly with distinct operations. We don't really have the machinery for that in Swift today, and I don't think we should try to add these structures to the standard library without it.
Numeric is a special case that made sense to add, in that "a ring with unity with the usual operators" is a common enough thing that it's useful to have on its own, rather than as a more abstract Ring structure, and it's deliberately not named Ring for the reasons sketched above.
Arithmetic or something like it, may or may not make sense to add, but the criteria according to which it should be considered are similar--is it a set of operations that is semantically useful separate from its meaning as an abstract mathematical structure.
All that said, I agree broadly with @yxckjhasdkjh: if you want to conform VectorFoo protocols to this protocol, then having multiplication is at least controversial, and probably doesn't belong. Every vector space can be endowed with a product that makes it into an algebra (the elementwise product works anytime you have "elements", and even in the most abstract settings you can always add the zero product that just maps a*b to zero for every a, b), but that is not a useful or meaningful operation in every setting that is a vector space, and which we would want to conform to such a protocol.
So, I think the API surface of this protocol, if it's going to be added, is:
public protocol Arithmetic : Equatable {
static var zero: Self { get }
prefix static func + (x: Self) -> Self
prefix static func - (x: Self) -> Self
static func + (lhs: Self, rhs: Self) -> Self
static func - (lhs: Self, rhs: Self) -> Self
static func += (lhs: inout Self, rhs: Self) -> Self
static func -= (lhs: inout Self, rhs: Self) -> Self
}
I left the Arithmetic name here for clarity, but given the absence of *, another name will probably be a better fit. This is, mathematically, an additive group, but I think that we should avoid that name if we can, for reasons sketched above.