Add trait that allows using `as` operator for generic code about num-traits HOT 10 CLOSED

AsPrimitive was added in #17, and released back in num-traits 0.1.42.

from num-traits.

From @Binero on March 29, 2016 21:27

It also appears impossible to cast from f32 or f64 to num::traits::Float.

from num-traits.

From @bluss on March 29, 2016 21:33

Yes, Float is not a "trait object compatible" trait (a.k.a. "object safe"), so it can not be used as a type like that. I don't think that's expected, not every trait is made to be object compatible.

from num-traits.

From @Binero on March 31, 2016 13:8

It does make code generic over Float very hard to write, as it's not possible to use constants. In my specific instance, I had to multiply the Float input by Euler's number, which was impossible. I cannot make a Float from an f64.

from num-traits.

From @bluss on March 31, 2016 13:30

Euler's number is accessible from Float though, F::exp(F::one()) where F: Float. Not so nice maybe..

from num-traits.

From @bluss on March 31, 2016 13:32

I'm using asprim in the mean time, but it is much better for crate interoperation if this kind of feature is already included in the float trait.

from num-traits.

From @hauleth on July 15, 2016 9:55

You can always use FromPrimitive or From.

from num-traits.

From @Enet4 on November 2, 2017 11:12

Just bumping this issue, as I believe that this crate could benefit from an AsPrim trait. I have a use case where an N-dimensional volume of primitive elements are linearly transformed and converted to a compile-time value type T on reading. The other traits don't work because I would prefer precision loss over not obtaining a value at all. The asprim crate is nice, but this being covered by num is almost a normal expectation, and would more easily implement the trait for other numeric types such as Complex.

from num-traits.

more easily implement the trait for other numeric types such as Complex.

It's an infallible conversion -- would you just silently drop the imaginary part? I think it's better to make that explicit, like value.re.as_().

from num-traits.

From @Enet4 on November 2, 2017 16:50

It's an infallible conversion -- would you just silently drop the imaginary part? I think it's better to make that explicit, like value.re.as_().

That is true, this conversion might bring some confusion. The main problem is that I'm dealing with the boundaries between a data type only known at run time and a compile-time type decided by the API user. Perhaps I need to rethink my approach, but I couldn't make such a conversion explicit (at least not without specialization or something similar).

from num-traits.