"Open questions" moved to GitHub issues

doc/DESIGN.md

@@ -842,44 +842,3 @@ In order to extend the library with custom dimensions the user has to:
       constexpr auto operator""_B(long double l) { return units::quantity<byte, long double>(l); }
     }
     ```
-
-
-## Open questions
-
-1. Should we ensure that dimension is always a result of `derived_dimension` and unit is a result
-    of `derived_unit`? How to do it?
-
-2. What to do with `std::chrono::duration`?
-
-3. Should we provide `seconds<int>` or stay with `quantity<second, int>`?
-
-4. What is the best way to add support for temperatures?
-
-    Temperature absolute values not only require `std::ratio` but also should be adjusted/shifted
-    by some constant values (i.e. [°C] = [K] − 273.15). Relative temperatures does need an offset.
-    Users will most probably have problems with differentiating those two. Maybe the best solution
-    is to provide only `K` support in quantity and provide non-member helper conversion functions
-    with verbose names to convert to `°C` and `°C`?
-
-5. Do we need a non-linear scale?
-
-6. Should we provide integral UDLs or just leave floating point ones?
-
-7. Should we provide support for dimensionless quantities?
-
-    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.
-
-8. Should we standardize accompany tools (downcasting facility, `type_list` operations, `common_ratio`, etc)?
-
-9. `k`, `K`, `W`, `F` UDLs conflict with gcc GNU extensions (<https://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Fixed_002dPoint.html>)
-    for floating point types.
-
-10. `J` UDL conflicts with imaginary constants GCC extension
-
-11. `erg` (CGS energy) UDL conflicts with engineering syntax
-
-12. Do we need custom/multiple systems?
-
-13. How "moment of force" is different from "energy"?