Oh, now I start to understand what you meant. Thanks!

We could definitely provide pairs of UDLs just for Celsius and Fahrenheit:
- 4abs_deg_C - quantity_point
- 4abs_deg_C - quantity_point
- 4rel_deg_F - quantity
- 4rel_deg_F - quantity

and maybe also disable the multiply syntax for those. This should increase
the chances of coding things correctly. However, as Sebastian mentioned,
the user who is not aware of quantity_points or those UDLs would still be
able to make it wrong.

I am also not sure if we should do the same for all the rest of the units,
considering the number of issues that UDLs introduce.

śr., 19 cze 2024 o 12:00 Ville Voutilainen <ville.voutilainen_at_[hidden]>
napisał(a):

> On Wed, 19 Jun 2024 at 12:41, Mateusz Pusz <mateusz.pusz_at_[hidden]> wrote:
> >
> > Ville, thanks for the clarification.
> >
> > I am not sure if we need one more entity in the library, which is also
> quite expensive to standardize and has the issues I mentioned before. Also,
> it will not create a `quantity_point` but a `quantity` type (consistently
> with chrono UDLs creating `duration` and not `time_point`), so I am not
> sure how it helps in solving the issue mentioned in this thread.
>
> The idea would be that 28deg_C creates a temperature in Celsius that is
> not 28K.
>