@@ -13,10 +13,9 @@ use crate::simd::intrinsics;
1313use crate :: simd:: { LaneCount , Mask , MaskElement , SupportedLaneCount } ;
1414
1515/// A SIMD vector of `LANES` elements of type `T`. `Simd<T, N>` has the same shape as [`[T; N]`](array), but operates like `T`.
16- /// This type is commonly known by names like `f32x4` or `Vec4` in many programming languages.
1716///
18- /// Two vectors of the same type and length will, by convention, support the binary operations (+, *, etc.) that `T` does.
19- /// These take the lanes at each index on the left-hand side and right-hand side, perform the binary operation,
17+ /// Two vectors of the same type and length will, by convention, support the operators (+, *, etc.) that `T` does.
18+ /// These take the lanes at each index on the left-hand side and right-hand side, perform the operation,
2019/// and return the result in the same lane in a vector of equal size. For a given operator, this is equivalent to zipping
2120/// the two arrays together and mapping the operator over each lane.
2221///
@@ -29,14 +28,14 @@ use crate::simd::{LaneCount, Mask, MaskElement, SupportedLaneCount};
2928/// let zm_mul = a0.zip(a1).map(|(lhs, rhs)| lhs * rhs);
3029///
3130/// // `Simd<T, N>` implements `From<[T; N]>
32- /// let [ v0, v1] = [a0, a1].map(|a| Simd::from(a ));
31+ /// let ( v0, v1) = (Simd::from(a0), Simd::from(a1 ));
3332/// // Which means arrays implement `Into<Simd<T, N>>`.
3433/// assert_eq!(v0 + v1, zm_add.into());
3534/// assert_eq!(v0 * v1, zm_mul.into());
3635/// ```
3736///
3837/// `Simd` with integers has the quirk that these operations are also inherently wrapping, as if `T` was [`Wrapping<T>`].
39- /// Thus, `Simd` does not implement `wrapping_add`, because that is the behavior of the normal operation .
38+ /// Thus, `Simd` does not implement `wrapping_add`, because that is the default behavior .
4039/// This means there is no warning on overflows, even in "debug" builds.
4140/// For most applications where `Simd` is appropriate, it is "not a bug" to wrap,
4241/// and even "debug builds" are unlikely to tolerate the loss of performance.
0 commit comments