What is your evaluation of the proposal?
I am huge +1 on adding SIMD types to the standard library, and on the design in general.
However, I’m missing a more detailed description of all the types proposed. The proposal only lists the concrete types briefly and describes the most important protocols, saying that the rest is self-explanatory. That makes it hard to understand exactly what is proposed. You either have to read through the PR (which is heavily gybbed), or build a toolchain yourself to try it out.
This feels like a break from the standard process. I can’t think of a single proposal that I haven’t been able to review by reading the text alone. Even large proposals like SE-0166 have included all the code examples necessary to understand exactly what’s proposed.
I wonder if this might be why several people have said that they don’t have the time to review this fully.
Is the problem being addressed significant enough to warrant a change to Swift?
Yes. These are fundamental currency types, and should be included in the standard library.
Does this proposal fit well with the feel and direction of Swift?
Yes, in general. But a few things stick out:
.* spelling for elementwise multiplication feels inconsistent with the other arithmetic operators, especially
/. I would have expected it to be just
Having standard equality and/or comparison operators that don’t return
Bool is confusing, as pointed out by many. Changing the elementwise equality operator to
.==, but not changing the elementwise comparison operators is even more confusing. Whatever spelling is chosen, both elementwise equality and elementwise comparison operators should use it.
_all() -> Bool and
_any() -> Bool methods on
SIMDMask feel unswifty to me. Since they just return simple computed values, they should be properties, not methods. And since they are perfectly usable by themselves, and not just as customization points, they shouldn’t be underscored. A better spelling would be
var all: Bool and
var any: Bool.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I’ve done graphics programming in shaders (Cg/HLSL) and Unity (C#), and some in Swift using structs and
simd.h. Compared to those, a few things stand out as missing without a clear motivation:
What is the motivation behind not including standard property names
w for 2, 3 and 4-component vectors?
What is the motivation behind including
oddHalf swizzles, but not
What is the motivation behind including square root but not geometric operations like dot product, cross product, magnitude, magnitude squared, etc? Is the user supposed to write those themselves, or are they coming in a later proposal? Or are they at another "level" than these types?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Participated in the pitch thread, read the proposal, dug through the PR.