Add as_raw_number(...) utility

[chiphogg]

This lets us pave the way to change the behavior of quantity arithmetic
when all units cancel out (#185). If we make this change all at once,
it'll generally be too big and hard to handle. But if we provide this
utility now, then people can migrate individual callsites gradually over
time. Then, at the end (probably 0.5.0?), making the switch to the new
behavior won't be such a big change.

Helps #185.

[geoffviola]

Sounds like this change will help migrate.

I feel like .in(unos) isn't great if the quantity wasn't a unos to begin with. But I do like keeping in the tradition of mentioning the type somewhere in the conversion statement. For example,

auto foo_p = percent(0.7);
...
double foo_d = foo_p.in(percent);

seems better than

auto foo_p = percent(0.7);
...
double foo_d = as_raw_number(foo_p);

[geoffviola]

Commend: Thanks for this clarification. I was worried about cases like as_raw_number(seconds(1)).

[chiphogg]

Sounds like this change will help migrate.

I feel like .in(unos) isn't great if the quantity wasn't a unos to begin with. But I do like keeping in the tradition of mentioning the type somewhere in the conversion statement. For example,

auto foo_p = percent(0.7);
...
double foo_d = foo_p.in(percent);

seems better than

auto foo_p = percent(0.7);
...
double foo_d = as_raw_number(foo_p);

Great analysis, and I agree. The main use case for using as_raw_number with non-unitless dimensionless quantities is for results of calculations. This will let somebody write as_raw_number(frequency * duration), and have it continue to work even when we refactor to use more convenient units for frequency or duration --- as long as the combination can be safely converted to a raw number.

[chiphogg]

Sounds like this change will help migrate.

I feel like .in(unos) isn't great if the quantity wasn't a unos to begin with. But I do like keeping in the tradition of mentioning the type somewhere in the conversion statement. For example,

auto foo_p = percent(0.7);
...
double foo_d = foo_p.in(percent);

seems better than

auto foo_p = percent(0.7);
...
double foo_d = as_raw_number(foo_p);

Oh! And just to be crystal-clear, foo_p.in(percent) has different semantics than as_raw_number(foo_p) --- the former gives 0.7, while the latter gives 0.007 (or, in each case, as nearly as we can represent those values in double).

Non-unitless dimensionless units are really hard. 😅