Portability with nalgebra

[js2xxx]

I wonder if every Complex<T> in the implementation could be replaced with ComplexField<RealField = T> or SimdComplexField<SimdRealField = T> trait in nalgebra so that library implementations based on these 2 crates can be more generic and portable. That's a huge change indeed, but I'm still looking forward to the possibility.

BTW, I've seen the issue #85, which seems to be a particular case of above. I don't quite know about nalgebra's SIMD operations and whether its co-op with this crate would slow down much. But I'm interested to how it would work.

[ejmahler]

I love the idea of making rustfft more interoperable with other crates. This would be a breaking change, so at minimum, we can't do it for another year. After that, I'm torn, because that would be a very, very large commitment.

Something we do in the AVX code to get around the lack of specialization is to have two different numeric traits (one user-facing and one interal), assert that they're the same type with std::any, then just transmute one to the other. Could we take the same approach here, where we expose an API that accepts nalgebra's types, and internally we transmute them to Complex behind the scenes? That would let us put the nalgebra integration in a different crate and avoid such a massive change, while still providing usability improvements to users.

I'll leave this open and think about it.