Merge #100

100: Add support for `bytemuck` traits r=cuviper a=bradleyharden

`bytemuck` seems to be the *de facto* standard crate for safe
transmuting. Because `Complex<T>` is `repr(C)`, it would satisfy the
requirements for `Zeroable` and `Pod`, as long as `T` satisfies them as
well.

Add optional implemenations of `Zeroable` and `Pod`, gated behind the
`bytemuck` feature.

Closes #99

Co-authored-by: Bradley Harden <bradleyharden@gmail.com>
Co-authored-by: Josh Stone <cuviper@gmail.com>

Author: 3 people

Cargo.toml

@@ -14,10 +14,14 @@ exclude = ["/bors.toml", "/ci/*", "/.github/*"]
 edition = "2018"
 
 [package.metadata.docs.rs]
-features = ["std", "serde", "rand"]
+features = ["bytemuck", "std", "serde", "rand"]
 
 [dependencies]
 
+[dependencies.bytemuck]
+optional = true
+version = "1"
+
 [dependencies.num-traits]
 version = "0.2.11"
 default-features = false

ci/test_full.sh

@@ -28,6 +28,7 @@ if ! check_version $MSRV ; then
 fi
 
 FEATURES=(libm serde)
+check_version 1.34 && FEATURES+=(bytemuck)
 check_version 1.36 && FEATURES+=(rand)
 echo "Testing supported features: ${FEATURES[*]}"
 

src/lib.rs

@@ -599,6 +599,18 @@ impl<T: FloatCore> Complex<T> {
     }
 }
 
+// Safety: `Complex<T>` is `repr(C)` and contains only instances of `T`, so we
+// can guarantee it contains no *added* padding. Thus, if `T: Zeroable`,
+// `Complex<T>` is also `Zeroable`
+#[cfg(feature = "bytemuck")]
+unsafe impl<T: bytemuck::Zeroable> bytemuck::Zeroable for Complex<T> {}
+
+// Safety: `Complex<T>` is `repr(C)` and contains only instances of `T`, so we
+// can guarantee it contains no *added* padding. Thus, if `T: Pod`,
+// `Complex<T>` is also `Pod`
+#[cfg(feature = "bytemuck")]
+unsafe impl<T: bytemuck::Pod> bytemuck::Pod for Complex<T> {}
+
 impl<T: Clone + Num> From<T> for Complex<T> {
     #[inline]
     fn from(re: T) -> Self {