Type for an array of dynamic scalar type?

[drewm1980]

I am working on code that deserializes data that originated from numpy (but is in a nonstandard serialized format), and could have any of the supported scalar types from numpy (but in practice I'll only support rust native numeric types).

Every type I've found in the API is (compile-time) generic over the contained scalar type (f32,f64,...), but I need a type where the scalar type is dynamic for the return value of my deserializer.

Is this already supported by the ndarray crate? An option is to roll my own enum around ndarray's concrete types.

For example, the image library has this as the return type of their deserializer: https://docs.rs/image/0.23.14/image/enum.DynamicImage.html

[jturner314]

Yeah, ndarray's ArrayBase type is always generic over the element type.

An option is to roll my own enum around ndarray's concrete types.

That's what I'd suggest if you need dynamic element types. I'm a little surprised that the numpy crate doesn't provide a type like this. It looks like the array type in the API they expose is always generic over the element type.

Another route would be to box ndarray::Arrays into Box<dyn std::any::Any> (and expect the user to downcast the array). Personally, I avoid Any, though.

If possible, I'd suggest making your deserializer generic over the element type instead of using some form of dynamic element types. That's what I've done in the ndarray-npy crate, for example.

[bluss]

A type-erased array makes sense - or an enum around an array like DynamicImage - but I don't think it fits inside this crate for now. So I really mean that it makes sense to use but we won't provide it right now - in particular, let the types you use/allow be guided by your use case in your own implementation of the idea. I've written a type erased array wrapper before, but it seems quite tricky to get right.

This would be something we possibly would attempt after #879 and #339 are done, which is pretty far future right now.

[drewm1980]

Thanks for the responses! Indeed, I can make at least ~some simplifying assumptions, and it's good to know I'm on the right track with the enum approach. The data structures I'm deserializing can be arbitrarily nested and contain multiple arrays; making the whole serializer generic of over the inner types doesn't seem like a good fit; there are too many types and I don't control them all.