I never said that there are no possible pitfalls in this or any other library, and I also never tried to hide them. I even provided a dedicated chapter for this specific issue: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3045r1.html#potential-surprises-while-working-with-temperatures to raise discussions like this one and possibly find a better solution.

Unfortunately, so far, we have not found it.

As it was stated in this thread there are use cases for both temperature points and temperature deltas in units like Celsius or Fahrenheit. Many of our users do not know what a Rankine is, and we should not expect them to learn or use it. Also, as Chip mentioned, I do not believe that the addition or subtraction of two quantities with the same unit should yield a totally different unit (Kelvin for degree Celsius input, Rankine for degree Fahrenheit input). That would be really surprising and would complicate the framework.

However, I do not think that this library is "unfit for standardization". There are some basic concepts that have to be learned, and programmers will not be able to use the library efficiently or even correctly if they do not understand the concept of the affine space design. Fortunately, this is nothing new. We have it in chrono for many years now, and no one is confused with the code below:

  using namespace std::chrono_literals;

  using Clock = std::chrono::steady_clock;
  using TimePoint = std::chrono::time_point<Clock>;

  std::chrono::duration d(3s);
  TimePoint ts(3s);

I think that the solution provided by me in the first answer (https://godbolt.org/z/E8bf51hKG) is not harder to understand. Still, we are open to ideas. Please do let us know if you have a solution that simplifies things and does not break cases that work nicely already.

Best

Mat

wt., 18 cze 2024 o 20:53 Tiago Freire <tmiguelf@hotmail.com> napisał(a):

But I think we are deviating from my original objective.

Which is not “my implementation of a units library” but “is this implementation fit for standardization”, if we did not had an alternative doesn’t mean we should adopt this one.

 

Would we want to adopt this one and paint ourselves into a corner, or should we keep looking for a better design that never introduces these issues to begin with.

The premise is, adopt this one because it is safe and user-friendly. But is it safe? Is it user-friendly?