ngzhian
commented
3 years ago One (far out) consideration is the flexible-vectors proposal. When that happens they might want a vec type, and we might have to back this change out.
Ignoring that, I think "internally", vec sounds good, I can imagine a vec functor that can be initialized to 128-bits for SIMD128. However I think at the "interface", sticking to something closer to SIMD 128 (e.g. s128/v128) might be better, as it suggests that this is a fixed-size data type, and also because it matches the current SIMD spec more. That said, the terms we use in the spec can also be changed to refer to vec.
Overall, I think if we want to rename this, I prefer v128/s128:
- it is closer to i32/i64/f32/f64,
- it suggests that it is fixed-size,
- avoid future conflict
This rename can happen at the interface (ast, types, operators). We can keep vec in the internals (eval).
rossberg
This is a test PR for renaming simd types to vector types.
@ngzhian, what do you think? I know that it was me who originally suggested calling them "simd" types rather than vector. But on reflection, I think you were right all along, and I came around to think that "vector" is more adequate. Also more in line with the name v128. After all, the values of this type are simply vectors, not "single instructions multiple data". :)
(I think my original reason for avoiding vector was to prevent confusion with the existing notion of vec in the spec. But I think we can just as well rename that to list or sequence.)