Adam Reichold

I think the [`libm` crate](https://crates.io/crates/libm) can be used in `no_std` environments as it is a pure Rust reimplementation of MUSL's libm.

> Add fn powf(e: f32) -> V. Result is the underlying storage type no longer constrained by dimension. I am not sure this adds anything beyond taking the bare value...

> without generic associated types there is no way to ask a Units implementor for its equivalent Units implementor AFAIU I think we could add a separate trait ```rust trait...

The trait bound which did not work out for me was ```rust Ul: Units + Units + ?Sized, ``` as e.g. `SI` would only implement `Units` but not say `Units`.

Note that the fields of `Quantity` are public, so if have you two quantities in the same system of units where only the base type is different, you can do...

One problem I see for expressing the absolute/relative distinction at the type level is that having numerical values for absolute values requires a choice of origin as the numeric values...

> Thoughts? I think the established procedure is to expose these trait implementations as optional dependencies but this can get messy, e.g. supporting multiple incompatible versions or alternative crates, c.f....

> Is some kind of macro prelude necessary? Couldn't the nested macros just be fully qualified using the `$crate` meta-variable?

Personally, I think a `new_with_base_units` const fn does not provide a lot of benefit compared to a struct literal like ```rust const FOO: Bar = Quantity { dimension: PhantomData, units:...

> Would we have two different code paths for const/non-const? I think this is necessary because a trait that requires a function/value to be available in const context cannot be...