Thank you for your answer, very informative and helpful.

On Sun, Apr 13, 2025 at 7:15 PM Howard Hinnant <howard.hinnant_at_[hidden]>
wrote:

>
> Nevertheless, type_traits was a huge success because it enabled a vast
> amount of introspection with a relatively uniform API that was not
> previously availalbe. This library was so successful that it was
> standardized in C++11. In 2011 work had begun on concepts, but attempts to
> standardize it in that time frame failed. The concepts technology was not
> yet mature.
>

I agree about std::is_integral, but still it was unclear to me that just
mapping/wrapping is_integral to integral was the right call.
I say was because since I have asked you this question I have actually come
up with a nice counterexample. I can not think of reasonable "operator" way
to distinguish between floating point and fixed point numbers.
https://en.wikipedia.org/wiki/Fixed-point_arithmetic
Now this does not mean could not have ended up with std::integral and
something that is not std::floating_point (maybe std::fractional to unify
fixed and floating point numbers?) with operator concepts, it just shows it
is not as easy as I assumed.


> So both the “type list” and “operator” approaches are important tools in
> the toolbox. On the “operator” side I should point out that a class type
> need not support all opertions to be used with a library like <chrono> if
> it is only going to be used with a subset of that library. For example if
> you only add two durations using your custom rep, your custom rep need not
> support subtraction.
>

This is a hard question, I presume you are familiar with Bjarne cowboy
example. In other words I am not sure having concept for everything helps
enough to justify it's existence. In other words sure if you restrict type
to minimum number of operations required that is nice, but assume you have
simple counter logic that is templated on Counter type... how many bugs are
you preventing because your Counter concept supports types that do not have
decrement or division? I presume not much. But I am not a library
developer, so I trust your judgment on this.

I will just add a third option that is not a type list or operator way:
type will tell you :)

template <typename T>
concept fp_number = std::numeric_limits<T>::is_specialized &&
!std::numeric_limits<T>::is_integer;


Tricky part here is if we can assume !is_integer means floating point, or
numeric_limits should work with fixed point numbers also. I tried reading
the standard and unfortunately it does not seem obvious, i.e. is standard
here talking just about std:: types (and users are fine to add
specializations for fixed point numbers or numeric_limits works just for fp
and integral types):
Specializations shall be provided for each arithmetic type, both
floating-point and integer, including bool.
<https://eel.is/c++draft/numeric.limits#general-4.sentence-1>

The member is_specialized shall be true for all such specializations of
numeric_limits.
<https://eel.is/c++draft/numeric.limits#general-4.sentence-2>