Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager (via direct message in the Swift forums).
What goes into a review of a proposal?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift.
When reviewing a proposal, here are some questions to consider:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Is the problem being addressed significant enough to warrant a change to Swift?
Yes. I encountered this a little while back and was frustrated specifically that Vector Spaces don't really fit in the current model.
Does this proposal fit well with the feel and direction of Swift?
Yes.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I think that we stray a little too far from the algebraic abstractions even with this change but it will make it more manageable.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study? As I wrote above, I've encountered the issue before via Strideable. I read through the proposal.
One issue I would like to raise is that it would be nice if we could satisfy Strideable and the requirements for Strideable.Magnitude by using init(repeating: Scalar, shape: Self) { ... } OR static func * (lhs: Self, rhs: Self) -> Self { ... } since Strideable could be defined in terms of a vector space or a ring. While this is–in some ways–a separate issue, the rearranging we do here could be altered to make changing Numeric simpler.
+1
It strikes a good balance between being mathematically correct and also practical to use.
I believe so. Vectors are very common structures in some domains and it makes a lot of sense to generalise what vectors and numbers have in common.
Yes, also the naming feels Swift-y to me.
I don't know any language that has an even halfway decent abstraction about numbers in its stdlib, Haskell's is weird too.
Participated in the original thread and read the proposal carefully.
Some additional notes:
I'd like to include the term "additive group", or just "group" somewhere in the documentation because it's one of the most common algebraic structures and it would be good if people who are interested were able to look up more information on that term; also lots of people who work e.g. with vectors might already know what a group is. The name AdditiveArithmetic is IMHO completely fine, though.
Mathematically, subtraction is usually defined via inverses, i.e. a-b = a+(-b). It can definitely be done the other way around though, that is -a = 0-a. Is there going to be a prefix - function defined for this type?
The protocol requires implementations of += and -=. What does that mean for immutable types, and couldn't those be implemented purely in terms of + and -?
Maybe a minor thing, but why does AdditiveArithmetic need to require Equatable?
We'll want to be a little bit careful with this, as this structure is not quite a group (though it is definitely group-ish). In particular, inverses do not necessarily exist for FixedWidthInteger types that conform to this protocol (or at all for UnsignedInteger types), and addition is not associative for either BinaryInteger or FloatingPoint types that will conform.
No. This protocol is not the right place for negation. Consider whole number types like UInt. Subtraction makes sense, but negation (−x) can only ever trap. Why even let it compile?
Here are three examples of what I'm talking about:
1 as UInt has no additive inverse, because there is no UInt value x for which 1 + x == 0.
If Int were an additive group, then (Int.max + 1) + (-1) would be the same as Int.max + (1 + (-1)), hence Int.max. But, because of overflow traps, FixedWidthInteger addition is not associative.
If Double were an additive group, then 1 + (1 + 0x1.0p53) would be equal to (1 + 1) + 0x1.0p53. But because of intermediate rounding, floating-point addition is not associative:
Is the problem being addressed significant enough to warrant a change to Swift?
Yes.
Does this proposal fit well with the feel and direction of Swift?
Yes.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I haven't actually used another language with a numeric type hierarchy like Swift has.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I read the proposal, the feedback, and the pre-pitch thread.
Is the problem being addressed significant enough to warrant a change to Swift?
Yes. Vectors should be an important part of the Swift numerical support.
Does this proposal fit well with the feel and direction of Swift?
Yes.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
N/A
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I have read the proposal and the pitch discussion.
Given that this protocol is not the right place for negation, is it worth moving unary + from Numeric up to AdditiveArithmetic? Its stated purpose is for symmetry with unary -, so if anyone is writing generic code over AdditiveArithmetic, there's no real reason to use unary +.