No common_type between CNL types

[mpusz]

What are you trying to do?

int s behave as the following:

int16_t i16 = 42;
static_assert(std::is_same_v<decltype(-i16), int>);
static_assert(std::is_same_v<std::common_type_t<decltype(i16), decltype(-i16)>, int>);

Negation of the short type results in an integral promotion to int. Both of those types have common types.

When I try to do the same for CNL types, the integral promotion happens, but the results do not have a common type with the source type:

using cnl16_t = cnl::scaled_integer<int16_t, cnl::power<-2>>;
using cnlint_t = cnl::scaled_integer<int, cnl::power<-2>>;

cnl16_t cnl16 = 42;
static_assert(std::is_same_v<decltype(-cnl16), cnlint_t>);
// static_assert(std::is_same_v<std::common_type_t<decltype(cnl16), decltype(-cnl16)>, cnlint_t>);  // does not compile - no common type

Repro here: https://godbolt.org/z/W8xrbncch

Is this behavior intentional?

Why does it matter?

It was discovered by the mp-units representation type constraints that, as of today, require the following:

template<typename T, typename S>
concept ScalableWith = requires(const T v, const S s) {
  { v * s / s } -> std::common_with<T>;
  { s * v / s } -> std::common_with<T>;
  { v / s * s } -> std::common_with<T>;
};

template<typename T>
concept Addable = requires(const T a, const T b) {
  { -a } -> std::common_with<T>;
  { a + b } -> std::common_with<T>;
  { a - b } -> std::common_with<T>;
};

template<typename T>
concept WeaklyRegular = std::copyable<T> && std::equality_comparable<T>;

template<typename T>
concept NumberLike = Addable<T> && WeaklyRegular<T>;

template<typename T>
concept BaseScalar = NumberLike<T> && ScalableWith<T, T>;

From the above { -a } -> std::common_with<T>; makes CNL types not satisfy the current mp-units requirements.

I am not claiming that the above constraints are ideal, and feedback is welcome. Anyway, other libraries may do similar things, and they will face the same issues.

[johnmcfarlane]

Is this behavior intentional?

Yes, the compiler error is not the result of an unintentional omission of a specialization of common_type in CNL.

From the above { -a } -> std::common_with; makes CNL types not satisfy the current mp-units requirements.

Makes sense.

I am not claiming that the above constraints are ideal, and feedback is welcome.

common_type itself is not ideal. It works for the set of types centered around the fundamental types, but it isn't universally helpful because if gives one answer to many questions. For example, adding two 10-bit numbers gives you an 11-bit number, whereas multiplication gives you 20 bits. Should the result of all additions of elastic_integer<10> be 9-bits wider than necessary?

It seems like you are using common_type<A, B> where decltype(A@B) belongs, but I've not followed the project since late 2019 and am no expert.

[mpusz]

Not really. I use decltype where needed (e.g., in all binary operators), and I do agree that common_type is not a universal approach and should be avoided in such cases. This is one of the points where mp-units differs from std::chrono.

However, common_type is still useful in many cases. For example, we may want to:

• bring two types to a common type before comparison,
• return a common type from the ternary operator,
• provide a common type for a wrapper type (e.g., quantity) that requires getting common_type on the underlying type,
• find a common_type for storage in a container,
• ...

[johnmcfarlane]

Consider that CNL defines many binary operators and rep-like nesting about 5 levels deep, all with minimal reliance on common_type. I'm happy to be convinced (esp. with examples) that it is a requirement of numeric libraries in general. But it sounds like it's a requirement of mp-units, rather than a workaround.

[mpusz]

In my opinion, common_type is not for arithmetic, and it seems that you agree here.

I see it as the type that can hold one of a or b without loss of value. It is useful in many cases where you want to store or return a value while dealing with two different types. CNL does not seem to support this today.

[johnmcfarlane]

In my opinion, common_type is not for arithmetic, and it seems that you agree here.

Yes, though your example code seems to involve arithmetic quite a bit. Perhaps your concepts are structural, whereas I lean towards nominal for numeric types (from Foonathan's article).

I see it as the type that can hold one of a or b without loss of value.

On many architectures, std::common_type_t<float, int> cannot hold all values of either argument.

It is useful in many cases where you want to store or return a value while dealing with two different types.

It might be worthwhile looking at each of these cases in isolation starting with the most compelling in individual issues. I'd like to learn more about how common_type is useful.

In the meantime, it's possible for anyone to supply the glue code that satisfies mp-units particular requirements.

[mpusz]

Yes, I know that common_type and many other things are broken for the built-in arithmetic types 😉

[mattkretz]

common_type_t<T, U> started more or less as decltype(true ? declval<T>() : declval<U>()). So the design intent was to match the mathematical meaning of an operator?:. And the intent of ?: clearly is to store one or the other value. That we inherited broken language types from C is a historical quirk. One that we don't want to carry any further, I believe.
So I think it is fair to say that ?: and common_type have the semantics of "(can hold) one or the other value".
The issue I have with specializing common_type is that it's backwards. What we really want is to overload operator?:. Then common_type just falls out.