Reference specifiers

[mpusz]

Adds absolute<Reference> and delta<Reference> modifiers that will influence how:

• multiply syntax works
• limit invalid use cases for quantity and quantity_point.

Here are the main points of this new design:

1. All references/units that do not specify point origin (are not offset units) would be considered delta by default. This means that 42 * m will create a quantity and would be the same as calling 42 * delta<m>.
2. Multiply syntax is extended to allow quantity_point creation with the 42 * absolute<m> syntax. This will provide an implicit zeroth point origin.
3. For units that specify a point origin (kelvin, degree_Celsius, and degree_Fahrenheit), the user would always need to specify a modifier. This means that:

• 4 * deg_C does not compile
• 4 * delta<deg_C> creates a quantity
• 4 * absolute<deg_C> creates a quantity_point

4. Constrain constructors of quantity or quantity_point to require the same:

quantity q1(4, m);                       // OK
quantity q2(4, delta<m>);                // OK
quantity q3(4, absolute<m>);             // Compile-time error
quantity_point qp1(4 * m);               // OK
quantity_point qp2(4 * delta<m>);        // OK
quantity_point qp3(4 * absolute<m>);     // OK (move-constructor)

quantity q4(4, deg_C);                   // Compile-time error
quantity q5(4, delta<deg_C>);            // OK
quantity q6(4, absolute<deg_C>);         // Compile-time error
quantity_point qp4(4 * deg_C);           // Compile-time error
quantity_point qp5(4 * delta<deg_C>);    // OK
quantity_point qp6(4 * absolute<deg_C>); // OK (move-constructor)

Please note the above would also apply to Kelvin and Fahrenheit.

The delta and absolute modifiers are stripped upon construction, so the resulting quantity and quantity_point types will just use the underlying unit in its instantiation.

[Quuxplusone]

FWIW: As I said on std-proposals, I think relative is the wrong name, and would feel better if it were spelled delta.

For example, IIUC, you want 4 * absolute(deg_C) to create a quantity_point that is 4°C greater than the freezing point of water — i.e., +4 degrees relative to that point. And inversely, if I want to create a value that doesn't represent 4 actual degrees of temperature but rather 4 degrees relative to the ice point, then writing 4 * relative(deg_C) would be wrong and 4 * absolute(deg_C) would be correct. That, to me, is confusing.

I assume (and seem to confirm by reading https://github.com/mpusz/mp-units/blob/master/docs/users_guide/framework_basics/design_overview.md#point-origin ) that it's already possible to write

quantity_point qp5a = my::ice_point + 4*deg_C;  // OK, like your qp5 above

(It's certainly possible to write my::absolute_zero + 273'150*milli<kelvin>, as shown there.)
And I hope that it's already impossible to write

quantity_point qp4a = 4*deg_C;  // Error? like your qp4 above

If those are already true, then I wouldn't expect anything else to be necessary.

[chiphogg]

I didn't look at the code; I only read the summary.

I like it! Yes, there are questions about the names, but I think the mechanisms are promising.

I think it makes the multiply syntax for quantity points less objectionable than usual. It would still be nice if we could find a non-multiplicative spelling.

[mpusz]

IIUC, that should be // OK, based on point 3's

@JohelEGP, right! My bad. I just decided not to go with the 3-argument constructor (comma) and replaced that with a multiply syntax in the description without thinking too much about it. Of course, this is a copy-constructor. I just fixed that in the description. Thanks!

[mpusz]

I used absolute and relative because those names were proposed by Sebastian (https://lists.isocpp.org/std-proposals/2024/06/10163.php) and also Ville was OK with them (https://lists.isocpp.org/std-proposals/2024/06/10216.php).

But I also like delta better, so I will make an update soon.

[mpusz]

I decided to change the specifiers from being functions to variable templates. This is more consistent with the rest of library (e.g. kind_of<QS>). Functions should represent something that does computation. We use variable templates to add wrapping specifiers to types.