Question

I find this atrocious:

std::numeric_limits<int>::max()

And really wish I could just write this:

int::max

Yes, there is INT_MAX and friends. But sometimes you are dealing with something like streamsize, which is a synonym for an unspecified built-in, so you don’t know whether you should use INT_MAX or LONG_MAX or whatever. Is there a technical limitation that prevents something like int::max from being put into the language? Or is it just that nobody but me is interested in it?

Answer 1

Primitive types are not class types, so they don’t have static members, that’s it.

If you make them class types, you are changing the foundations of the language (although thinking about it it wouldn’t be such a problem for compatibility reasons, more like some headaches for the standard guys to figure out exactly what members to add to them).

But more importantly, I think that nobody but you is interested in it 🙂 ; personally I don’t find numeric_limits so atrocious (actually, it’s quite C++-ish – although many can argue that often what is C++-ish looks atrocious 😛 ).

---

All in all, I’d say that this is the usual “every feature starts with minus 100 points” point; the article talks about C#, but it’s even more relevant for C++, that has already tons of language features and subtleties, a complex standard and many compiler vendors that can put their vetoes:

One way to do that is through the concept of “minus 100 points”. Every feature starts out in the hole by 100 points, which means that it has to have a significant net positive effect on the overall package for it to make it into the language. Some features are okay features for a language to have, they just aren’t quite good enough to make it into the language.

Even if the proposal were carefully prepared by someone else, it would still take time for the standard committee to examine and discuss it, and it would probably be rejected because it would be a duplication of stuff that is already possible without problems.