Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explicit explanation of how to unwrap values (eg for serialization) #35

Open
spease opened this issue Feb 1, 2018 · 3 comments
Open

Comments

@spease
Copy link

spease commented Feb 1, 2018

There's a value_unsafe parameter, but it's unclear to me if that's the "right" way to do things if you just want to extract the value (sans the units). It'd be nice if this were explicitly stated somewhere, too, so that new users can discover it without asking.

Thanks!

@adeschamps
Copy link
Contributor

In this situation, I explicitly divide by what I expect the units to be. That should give you a dimensionless value. Then you can use the value() method from the Dimensionless trait. Note that value() returns a reference, so you'll have to dereference it as well:

fn send_speed_command(speed: si::MeterPerSecond<f64>) {
    let command = ApiCommand {
        speed_mps: *(speed / si::MPS).value(),
    };
    send(command);
}

@wellcaffeinated
Copy link

Just curious... why is there a specific type for dimensionless values? I would expect this to work instead:

let x :f64 = speed / si::MPS;

Also, i'd expect to be able to use an .into if there's a good reason for a unitless type

let x :f64 = (speed / si::MPS).into();

@droundy
Copy link
Contributor

droundy commented Jun 13, 2019

I think a dimensionless your is valuable because when you've got an f64 it may or may not actually hold a dimensional value, e.g. a distance a user provided. If an f64 were treated as dimensionless then it would be very hard to audit a coffee to ensure that all dimensions are correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants