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_at_[hidden]> 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?
>