@@ -13,10 +13,9 @@ use crate::simd::intrinsics;
13
13
use crate :: simd:: { LaneCount , Mask , MaskElement , SupportedLaneCount } ;
14
14
15
15
/// 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.
17
16
///
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,
20
19
/// and return the result in the same lane in a vector of equal size. For a given operator, this is equivalent to zipping
21
20
/// the two arrays together and mapping the operator over each lane.
22
21
///
@@ -29,14 +28,14 @@ use crate::simd::{LaneCount, Mask, MaskElement, SupportedLaneCount};
29
28
/// let zm_mul = a0.zip(a1).map(|(lhs, rhs)| lhs * rhs);
30
29
///
31
30
/// // `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 ));
33
32
/// // Which means arrays implement `Into<Simd<T, N>>`.
34
33
/// assert_eq!(v0 + v1, zm_add.into());
35
34
/// assert_eq!(v0 * v1, zm_mul.into());
36
35
/// ```
37
36
///
38
37
/// `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 .
40
39
/// This means there is no warning on overflows, even in "debug" builds.
41
40
/// For most applications where `Simd` is appropriate, it is "not a bug" to wrap,
42
41
/// and even "debug builds" are unlikely to tolerate the loss of performance.
0 commit comments