Bitv uses architecture-sized uints for backing storage

[Gankra]

Logging an issue against this first on the off-chance that there's a good technical reason for this. Bitv's are internally represented as a Vec of uints, instead of u32's or u64's. My understanding was that this is undesirable, as we only want to use uints/ints for memory/pointer-specific things. If we just want a pile of bits, this doesn't seem right.

[vks]

There are a few more places in the standard library: For instance pow uses uint for the exponent, which does not make any sense if you think about it as a "pointer only" type. Almost all examples involving integers use int.

I'm not sure there is a consensus on using int/uint for pointers and sizes only. Right now, all the documentation is encouraging the use of int.

[Gankra]

Right now, all the documentation is encouraging the use of int.

@steveklabnik notes that this is probably an issue with the docs in #15526

[pnkfelix]

I agree we need to figure out our story regarding int/uint; I've nominated #15526 for that.

In addition, while playing around with some code that uses Bitv, I wondered: would it be feasible for it to have a default type-parameter for the Key type, that puts a static bound on the size of the universe. The Key would presumably default to uint, i.e. today's type ... the reason that I was thinking this could be nice is that it might improve the ergonomics of using Bitv in the scenario where you are only working with 8- or 16- or 32-bit values, max; right now to use Bitv in such scenarios, you need to use checked casts (via to_type().unwrap()), which is unergonomic, or unchecked casts (via as), which is, well, unchecked.