Hi Lorro,   of course it is sloppy and not what the current proposal or the usage you wrote would be doing.   I was trying to talk about a user of the library with only basic understanding of usage. You wrote that it is clear from the calculation that we are getting a temperature difference. My argument is that the users of the library not always do those physically deriving calculations in code (with which it automatically gets the correct type), but could just read input data of that type from an external data source and would have to choose the correct unit (relative or absolute). Whether the main type is quantity (proposal) or quantity point (your suggestion), it should be explicit, which one is used.   Otherwise, for everyday use of temperatures, it would be a severe and easy source of error, which is also difficult to spot in code reviews (if you are not specifically looking for that).   I agree with you that some units - like the listed temperature, date, geospatial - are more often expressed as quantity point than as quantity.   Still, temperature is the major pain point of those. Especially as the units library handles types (quantity / quantity point), scale and reference points. So the library user relies on it doing the internal representation correctly.   Those unit types could/should also be used for interfaces, so the error could be distributed on two different persons/companies.   -----Ursprüngliche Nachricht----- Von:Lorand Szollosi <szollosi.lorand_at_[hidden]> Gesendet:Mi 19.06.2024 08:52 Betreff:Re: [std-proposals] On the standardization of mp-units P3045R1 An:std-proposals_at_[hidden]; CC:Sebastian Wittmeier <wittmeier_at_[hidden]>; Hi, 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