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".

His response was certainly more nuanced than that. Users are allowed to overload Boost.TypeTraits without it being UB like adding additional overloads in namespace std.

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"

Again, every-time we do not incorporate your suggestions we try and provide you with valid reasoning. Many of the libraries can't advance their language standard because 1 user says so. Since your other emails have been vocal about the supposed deficiencies in Math we don't like to make change for the sake of change. Math is at C++14, and will remain that way for the foreseeable future because that's what our large consumers use.

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. 

See: https://github.com/cppalliance/charconv/pull/153. Matt

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.