This should not happen implicitly in the framework. We had this issue in
mp-units V1 where the downcasting framework was doing the automatic
conversion for the user. With time and more experience in the domain we
found out this to be really wrong.

Hz = Bq = 1 / s

In the V1, `1 / s` always resulted in `Hz`, which made the framework
impossible to yield `Bq`. Also, someone implemented an application
that counted the number of cars passing a crossroad on the highway. They
got results in `Hz`, but they really wanted `1 / s`.
Consider also `Gy` and `Sv` or `rad` and `sr`. Also, power should be
measured in `W` but moment of force in `N * m`.

This is why I strongly believe that such conversions should be done
explicitly by the user.

śr., 19 cze 2024 o 03:03 Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> napisał(a):

> On Tuesday 18 June 2024 10:06:09 GMT-7 Charles R Hogg via Std-Proposals
> wrote:
> > A basic design principle for a units library is that the result of a
> > computation shouldn't conjure up any units not mentioned in the inputs.
>
> Why not? If I multiply an acceleration by mass, why should I not get
> newtons?
> If I divide a charge by time, should I not get amperes?
>
> PS: would this proposed API support a unit like ns/√km ?
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel DCAI Fleet Systems Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>