Getting a primitive type back out of a Rad

[anderspitman]

I'm trying to convert Rad to f32. Please see my Stack Overflow question here. I'm not seeing any way currently built into cgmath to do this. After looking at the source, for now I'm just using value.0. Seems brittle if ya'll change your internal representation though. Would you be interested in a PR implementing From? Something like the following:

impl From<Rad<T>> for <T> {
    fn from(r: Rad<T>) -> T {
        r.0
    }
}

Not sure if that's the right approach. Still fairly new to Rust.

[Osspial]

I don't see any real reason not do to this. That being said, I don't see us ever changing the representation of Deg or Rad away from the current one, so don't feel afraid to use them as-is.

[brendanzab]

Yeah, I think I was trying to avoid folks implicitly converting away the units all the time, but it might be nicer to have this. .0 is so ugly. 🤢

[anderspitman]

What about an explicit method call, like rad.as_float() or rad.to_float()? Doesn't seem very Rusty to my untrained eye though...

[Osspial]

I don't think that's necessary. Generally you should only have a non-generic method call if it performs some functionality that a straight field access doesn't, which isn't true here - the function would just be accessing the field, with parenthesis added. Implementing From or Into has the advantage of allowing Deg or Rad to be used in generic contexts.

If we do end up making access more explicit, I'd favor changing the .0 field to a named field, like .raw or .float, over adding another function. I don't really have a strong opinion on which is better, but I'm not sure it's worth breaking backwards comparability for what's a relatively minor ergonomics change.

[anderspitman]

I agree. Honestly even just adding a bit of documentation saying to use rad.0 would probably get us most of the way there.

On Fri, Apr 27, 2018, 10:56 AM Osspial [email protected] wrote:

I don't think that's necessary. Generally you should only have a non-generic method call if it performs some functionality that a straight field access doesn't, which isn't true here - the function would just be accessing the field, with parenthesis added. Implementing From or Into has the advantage of allowing Deg or Rad to be used in generic contexts.

If we do end up making access more explicit, I'd favor changing the .0 field to a named field, like .raw or .float, over adding another function. I don't really have a strong opinion on which is better, but I'm not sure it's worth breaking backwards comparability for what's a relatively minor ergonomics change.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/brendanzab/cgmath/issues/451#issuecomment-385047019, or mute the thread https://github.com/notifications/unsubscribe-auth/AHdTqCAFZ6psF0WdzKqKXX_6_MEp840uks5ts1vYgaJpZM4TLcxe .