On Sun, Apr 13, 2025 at 7:26 AM Ivan Matek via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> May I ask your opinion why std:: and your concepts are basically a fancy type lists and not something more abstract?

Because sometimes, you really want to deal with a fundamental type,
not a user-defined one that tries to act like a fundamental type.

> For example for std::floating_point I would expect certain operations like construction addition, division work “as expected” so that any 3rd party type is matched.
> I presume the issue is agreeing what a “as expected” is so std:: picked easier type list approach.
>
> On Sat, 12 Apr 2025 at 19:08, Howard Hinnant via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> Ancedote:
>>
>> std::integral recently fell out of favor with me and I wrote my own concept that better suited my needs:
>>
>> https://github.com/HowardHinnant/bbi/blob/master/bbi.h#L176-L191
>>
>> StandardSignedInteger
>> StandardUnsignedInteger
>> StandardInteger
>>
>> The difference here is that my concepts exclue bool and the character types. This distinction was at best not clear in C++11, and not modeled by the type_traits introduced then. For my work today, it is important to not include bool and the character types as “integral types” as their semantics are not consistent with the representaiton of integral numbers.
>>
>> I mention this ancedote as a word of caution for building further concepts on top of type_traits. type_traits was a good model of the type system when they were introduced, but may not be today, 15 years later.
>>
>> Howard
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals