Hi,

> On 19 Jun 2024, at 00:38, Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> A "climate scientist journalist" just reads in a survey file, what researches believe an expected temperature rise::
>
>
>
> From 100 climate scientists
>
> 5 believe in < 1.5°C
>
> 20 believe in 1.5-2.0°C
>
> 30 believe in 2.0-3.0°C
>
> 60 believe in 3.0°-4.0C
>
> 5 believe in >4.0°C
>

The notation in that table is incorrect, it seems to me that you’re using sloopy notation to prove your point. Those are C increases, or better yet, C differences.

I’m not saying it’s the same data type, exactly the opposite: I understand why we have quantity_point and quantity. However, as a user, I shouldn’t have to care about the underlying mechanism. What I wrote is, instead of making differences the input type and having to add them to a reference point (which is not the typical way of expressing yourself - you don’t say, ‘30C above the melting point of ice’, you say ‘30C’), use quantity_point as the main type for specifying constants and have difference as a derived value.

You wrote, approx.:
auto temp1 = ice_melting_point() + 30 * deg_C;
auto diff1C = 1 * deg_C;
temp1 * 1.1; // compile error

I suggested, approx:
auto temp1 = 30 _deg_C;
auto diff1C = 1 _deg_C - 0 _deg_C;
temp1 * 1.1; // well-defined, multiplies value in current units, it’s still an absolute temperature

Others also suggested that diff1C should have it’s constant / lit in the lib, namely, rel_deg_C and rename _deg_C (or deg_C) to abs_deg_C.

Also, in the second/third part of the mail I think I’ve described why this ice_melting_point() + 30 * deg_C will be even more troublesome when you try to describe e.g. financial and date units. It’s ambiguous and not the natural way to express yourself I think.

Thanks,
-lorro