From 62cf5ca493ea59600833eb409c2bd2b9bc611319 Mon Sep 17 00:00:00 2001
From: Mateusz Pusz <mateusz.pusz@gmail.com>
Date: Sun, 7 Apr 2019 08:34:47 +0200
Subject: [PATCH] Additional design questions added

---
 doc/DESIGN.md | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/doc/DESIGN.md b/doc/DESIGN.md
index 5c800b3e..51959d42 100644
--- a/doc/DESIGN.md
+++ b/doc/DESIGN.md
@@ -496,3 +496,35 @@ Additionally, it should make the error logs even shorter thus easier to understa
     Because dimensionless quantities have no associated units, they behave as normal scalars,
     and allow implicit conversion to and from the underlying value type or types that are
     convertible to/from that value type.
+
+17. Should we leave `quantity` and specific dimensions as
+    ```cpp
+    template<Dimension D, Unit U, Number Rep>
+        requires std::experimental::ranges::Same<D, typename U::dimension>
+    class quantity;
+    
+    template<Unit U = meter_per_second, Number Rep = double>
+    using velocity = quantity<dimension_velocity, U, Rep>;
+    
+    units::velocity<units::kilometer_per_hour> kmph = avg_speed(d, t);
+    ```
+    or maybe we should leave the dimension only in unit
+    ```cpp
+    template<Unit U, Number Rep>
+    class quantity;
+    
+    units::quantity<units::kilometer_per_hour> kmph = avg_speed(d, t);
+    ```
+    which will simplify the design and shorten compile time errors but possibly will add
+    more ambiguity to some cases. For example when using CTAD:
+    ```cpp
+    units::velocity kmph = avg_speed(d, t);
+    ```
+    vs
+    ```cpp
+    units::quantity kmph = avg_speed(d, t);
+    ```
+    It would be also incopatible with concepts named i.e. `Velocity`.
+
+18. Should we standardize accompany tools (`type_list` operations, `static_sign`, `static_abs`,
+    `static_gcd`, `common_ratio`)?