Why uniform_int_distribution with char template parameter is not allowed? [duplicate]

Question

As the documentation says:

The effect is undefined if this is not one of short, int, long, long long, unsigned short, unsigned int, unsigned long, or unsigned long long.

If I don't care about the range, I can just mask off the bits of a larger type to generate random numbers. If not, it's more complex. Why aren't the byte types provided just by default?

Answer 1

There is a library working group unresolved^[1] issue on this uniform_int_distribution<unsigned char> should be permitted and it says, amongst other things:

I am not aware of anything in <random> that works with 16-bit integers but fails with 8-bit integers, so I suspect that IntType and UIntType could simply be extended to permit the char family. Alternatively, this change could be limited to uniform_int_distribution alone, where it is definitely safe. A <random> expert should decide which change is best.

The proposed resolution is to change the restriction to allow standard integer types:

that has a template type parameter named IntType is undefined unless the corresponding template argument is cv-unqualified and is a a standard integer type (3.9.1 [basic.fundamental]

and:

that has a template type parameter named UIntType is undefined unless the corresponding template argument is cv-unqualified and is a standard unsigned integer type (3.9.1 [basic.fundamental])

This gets you unsigned / signed char although not uint8_t or int8_t but they are likely equivalent. Extended integral types were exluded to simplify the wording and maximize consensus:

This also excludes extended integral types and wide char types, which seem like nice-to-haves at best. I have no objection to supporting any of those types; I just picked this to simplify the wording and hopefully maximize consensus.

Note, this excludes char since it is implementation defined whether char is signed or not.

Note this topic was also brought up in the std-discussion list.

Jonathan Wakely notes this proposal is controversial and commented that his notes from the last discussion include the following:

that it was very definitely intentional that single byte integers are not supported, not an accidental omission, and so we should be careful about just changing that without consulting the designers of the C++11

He suggests adding a member to random_device to provide single bytes, which is seems like a reasonable alternative.

---

^{[1] The issue has been closed as "Not A Defect", meaning that it will not be resolved as a defect report. Instead a formal proposal for the change will be required.}