Now that the
target_feature RFC has some consensus it is time to discuss the next step towards SIMD on stable Rust.
From the discussions in the
target_feature RFC it seems clear that the next step is having an RFC about SIMD types. This summarizes the current state of affairs:
Implementation status: The feature
repr(simd)is currently implemented, its semantics are not sufficiently specified in any RFC, and some ABI issues must be resolved, but it can be used on nightly today to write SIMD types “just fine”.
Consensus from previous discussions: @burntsushi achieved consensus on trying to stabilize concrete SIMD types like
repr(simd). However, during the
target_featureRFC some ABI issues where discovered, and resolving them is going to require a more detailed specification of
repr(simd). Also, @nrc raised the question of whether we shouldn’t be using
#[repr(simd)] [T; N]on arrays instead of tuple structs. Since the type-level const RFC is (almost) merged we might want to reconsider this.
Anyhow, the purpose of this post is not to discuss the details of SIMD types, but to gather consensus on what is the next step. I think we have two main choices:
- have an RFC for the concrete SIMD types that we want to stabilize and their semantics, or
- have an RFC to specify
repr(simd)first, and then decide whether we want to stabilize
repr(simd)or only some SIMD types after that discussion is over.
I think that any discussion on the semantics of SIMD types is going to implicitly touch
repr(simd), so I find the second alternative, specifying
repr(simd), less messy. After that is done, an RFC for concrete SIMD types will be trivial to write anyway.