Mateusz Pusz
Mateusz Pusz
You can also say that those also have some numerical value 😉 I could argue that that others are not "quantities" but `duration` or `MyMetre`. Unless it is about the...
The same could be used to constrain `N m` to be used only with _moment of force_ or `V A` to be used with _apparent power_.
There are several problems here: 1. Derived units are not predefined in the code (they are dynamically composed as a result of unit equations), so there is no class template...
Well, it has at least two problems as well: 1. _moment of force_ is a quantity being a part of the system of quantity, and those should be units agnostic....
Interesting approach 😉 It has the "chicken egg problem", though. How can we define the first quantity in terms of a unit that is a quantity? Also, I wouldn't like...
I am afraid that even though it could improve the case here, it would break plenty of other use cases. For example, https://mpusz.github.io/mp-units/latest/users_guide/framework_basics/systems_of_units/#many-shades-of-the-same-unit. Units have very different rules than quantities,...
We never simplified `volume / length`. This was always mp-units thing ;-) We simplify only the same type identifiers.
Well, I did not plan to add any fancy interface (like `.in(Unit)`) to constants to not complicate the design. I thought that maybe being able to pass `si::standard_gravity` to `quantity`...
They actually work as a reference now, and we can type `1 * si::standard_gravity`, which is much shorter ;-)
Good points! Interfaces were different, but we unified them with #531. I am fine with refactoring as long as we do not provide public subsumptions between those two concepts. >...