Merge commit 'ec04d9c03ddf12e46dca5348d4ca57b526e425f1'

docs/design/quantity.rst

@@ -6,6 +6,11 @@ quantity
 Interface
 ---------
 
+    The value of a quantity is generally expressed as the product of a number and a unit. The
+    unit is simply a particular example of the quantity concerned which is used as a reference,
+    and the number is the ratio of the value of the quantity to the unit.
+
+
 `quantity` class template provides a similar interface to
 `std::chrono::duration <https://en.cppreference.com/w/cpp/chrono/duration>`_.
 The difference is that it uses ``double`` as a default representation and has

docs/framework/dimensions.rst

@@ -139,3 +139,68 @@ In order to obtain the base/coherent unit of any dimension type a
 
     static_assert(is_same_v<dimension_unit<si::dim_length>, si::metre>);
     static_assert(is_same_v<dimension_unit<si::dim_speed>, si::metre_per_second>);
+
+
+
+
+How do you feel about:
+
+inline constexpr second second;
+?
+
+We could do the same to dimensions to not have to type dim_length{} all the time.
+
+6 replies 2 new
+@JohelEGP
+JohelEGP
+2 days ago
+mp_units::units::second is a variable. The reference isq::si::second could stay a type and s continue to be a variable.
+
+@mpusz
+mpusz
+2 days ago
+Maintainer
+Author
+The problem is the following:
+
+Variables are really needed for a new design. We can ask users to put {} after every dimension unit, and reference types but it would be really nasty and a lot of boilerplate.
+Short names have to be opt-in as they collide with a lot of code (especially on MSVC).
+@JohelEGP
+JohelEGP
+yesterday
+As pointed out by #389 (reply in thread), I think it'd be OK suffix _t to the types.
+
+@mpusz
+mpusz
+10 hours ago
+Maintainer
+Author
+It will be visible in the compilation errors, which is inconvenient :-(
+
+Instead of:
+
+quantity<reference<derived_dimension<length_dim, per<time_dim>>, derived_unit<metre, per<second>>>
+we will have something like:
+
+quantity<reference<derived_dimension<length_dim_t, per<time_dim_t>>, derived_unit<metre_t, per<second_t>>>
+Personally, I like the first output more.
+
+Note that definition like:
+
+inline constexpr second second;
+besides, being really unconventional, is allowed by the language and will not impact our users at all. A user is about to always work with values in the code and observe types in the compilation errors. Using the same nicely blends those two domains together.
+
+@mpusz
+mpusz
+10 hours ago
+Maintainer
+Author
+I could use a list of values instead of types as template parameters in the dervied_dimension and derived_unit but in such case the error would look like:
+
+quantity<reference<derived_dimension<length_dim{}, per<time_dim{}>{}>{}, derived_unit<metre{}, per<second{}>{}>{}>>
+which also is not that nice.
+
+@JohelEGP
+JohelEGP
+6 hours ago
+That's convincing. This justification should definitely be part of the documentation.

docs/framework/units.rst

@@ -436,3 +436,18 @@ class template::
 
     To learn more about unknown units please refer to the
     :ref:`use_cases/unknown_dimensions:Working with Unknown Dimensions and Their Units` chapter.
+
+
+## System reference
+
+"It is important to emphasize that each physical quantity has only one coherent SI unit, even
+though this unit can be expressed in different forms by using some of the special names and
+symbols."
+The converse, however, is not true, because in general several different quantities may
+share the same SI unit.
+
+
+For example, for the quantity heat capacity as well as for the
+quantity entropy the SI unit is joule per kelvin. Similarly, for the base quantity electric
+current as well as the derived quantity magnetomotive force the SI unit is the ampere. It is
+therefore important not to use the unit alone to specify the quantity.