Consider providing constant instead of named_unit for constants

[mpusz]

Such constants could have superpowers. They could implicitly convert to a quantity and provide additional compile-time overflow protection as discussed in #669_

One possible problem is to decide which representation type should be used in case we want to allow CTAD (e.g., quantity{si::standard_gravity}). Forcing std::arithmetic types might be a no-go for some projects that use safe numeric wrappers. This is actually where the current unit-based approach shines. The constant is orthogonal to the representation type in a quantity.

[chiphogg]

One possible problem is to decide which representation type should be used in case we want to allow CTAD (e.g., quantity{si::standard_gravity}).

From my point of view, the right answer is straight forward: "we don't want to allow CTAD".

The mp-units-ification of the corresponding Au interfaces would probably look something like si::standard_gravity.in<T>(), creating a quantity whose rep is T, and whose unit is standard gravity (thus, holding a value of T{1}). And we could also have si::standard_gravity.in<T>(m/s/s) if we wanted a different unit --- and this operation would have the perfect conversion policy that you mentioned in the original post.

[mpusz]

Well, I did not plan to add any fancy interface (like .in<T>(Unit)) to constants to not complicate the design.

I thought that maybe being able to pass si::standard_gravity to quantity<isq::acceleration[m/s2]> would be enough.

Then I realized that we encourage people to use generic programming with concepts (e.g., QuantityOf<isq::acceleration> auto) which would not force the conversion and will not match the concept (the same as we discussed for Zero). This is why I thought that we may want to pass quantity{si::standard_gravity} in such cases, but this would require CTAD to work.

[chiphogg]

Yeah, it's on me to write a doc to explain the concept of "shapeshifter types". These are monovalue types that can "shapeshift" to become any type from some family of types. Zero and Constant are the classic examples, where the family of types is Quantity<U, R> (speaking "Au language" for the duration of this comment).

The "superpower" of a shapeshifter type is that it enables effortless comparisons, additions, subtractions, assignments, etc. with any one type from that family of types. You can simply "compare to ZERO", or "assign from SPEED_OF_LIGHT", and it will automatically generate the most efficient and correct code. This is a great benefit for expressibility!

Their weakness --- their "kryptonite", if you will --- is that you can only use them in a context where it's clear which type they need to become, which is not true for generic interfaces.

So, bringing a shapeshifter type to a generic interface is simply an incorrect usage. Once we have good explanations of shapeshifter types as a concept* that we can link to, then the community can learn that this simply isn't how to use them. And then we can get the benefits of the use cases where they do apply.

I am hoping to give a talk on Monovalue Types in CppCon 2025, and "shapeshifter types" will be a key component if I do.

Anyway: I really do think CTAD is the wrong direction to go here, because there's no way to get it without privileging some choice of rep above all others, and I want to avoid doing that.

*"As a concept": concept in the generic sense, not the C++20 sense, naturally.

[JohelEGP]

Why not give them the reference treatment, so that quantity{0, si::standard_gravity} works (note the 0 for an int rep)?

[mpusz]

They actually work as a reference now, and we can type 1 * si::standard_gravity, which is much shorter ;-)