Re: type traits

From: John Maddock (jz.maddock_at_[hidden])
Date: 2024-02-05 09:20:59

On 05/02/2024 01:02, g.peterhoff--- via Boost wrote:
>> So what's your point?
> Another example.
> I had asked for a TypeTrait is_integer and also supplied code for it (https://github.com/boostorg/type_traits/issues/186).
> The point is that is_integer only returns integer (no character, no bool).
> John immediately closed my request "We are not responsible for that".
>
> Instead of admitting a mistake (of course I make some myself) and saying "we forgot/didn't think of it, we'll do it", the only answer is "we don't care".
> That's thinking from the wallpaper to the wall.
> As I said, boost used to be progressive, but now when you make a suggestion, all you get is "We're not responsible for that/we're not interested in that/we might have to change something that's not possible"
>
> And this even with such a simple TypeTrait. Single file. No dependencies.
> And on the other hand, libraries with the most severe buffer overflows (charchonv) are included, where obviously no tests are carried out at all.
> 

Please don't think we don't care, however, please be aware that there 
are quite literally an infinite number of traits which *could* be added 
if we were so inclined.  Very early on the bar was set quite high, and 
the scope relatively narrow to keep things under control.  Plus your 
requirements for is_X may not be the same as my requirements for is_X.  
Your is_integer is a good case in point - character types as in 
[un]signed char most definitely are integers and are used as such for 
[u]int8_t.  I'm also tempted to suggest that numeric_limits is a better 
fit for your needs, given that that deals with semantics (behaves like a 
number) rather than types (type_traits).

If anyone would like to comment on the other issues g.peterhoff has 
raised, second opinions are always most welcome:

https://github.com/boostorg/type_traits/issues/185

https://github.com/boostorg/type_traits/issues/186

https://github.com/boostorg/type_traits/issues/187

https://github.com/boostorg/type_traits/issues/188

https://github.com/boostorg/type_traits/issues/189

https://github.com/boostorg/type_traits/issues/190

https://github.com/boostorg/type_traits/issues/191

https://github.com/boostorg/type_traits/issues/192

https://github.com/boostorg/type_traits/issues/193

https://github.com/boostorg/type_traits/issues/194

Aside number 1: it is probably long overdue for someone (but not me) to 
submit a "type_traits 2" which is something like C++17 or later, and 
much thinner and simpler than the old type_traits.

Aside number 2: There is probably also scope for a semantic traits 
library, ie does a type have all the semantics of an integer/float/bool 
or whatever.  Although whether that's better handled with concepts 
post-C++20 is a whole other topic.

Best, John.