[RFC] num: bitwise reflection methods

[lucab]

A bit-manipulation PR, however I still have some doubts:

• Library. I believe this is a pretty core operation for several algorithms (eg. many checksums), is the "battery-included" philosophy ok for libstd?
• Naming. Is reflect() too generic? That's how the operation is usually called, but may be too broad as API and conflict with reflection/introspection.
• Lot's of redundancy here: 8, 16, 32 and 64 variants. I tried implementing it more generically, however:
  • The Bitwise trait lacks One, Zero and NumCast for this implementation to work. Maybe they should be added anyway?
  • Is it possible to split impl Bitwise for i8..i64 in multiple files? Most of it is through instrinsics in each module, but ideally reflect() could be directly implemented in uint/int_macros abusing $T.

---

Let Bitwise provide a reflect() method for reversed binary
representation. This is a binary primitive used in several algorithms,
eg. CRC checksums.

[bill-myers]

The operation for bytes is usually called "byteswap", so maybe this could be called "bitswap", although someone might confuse bits and bytes.

Alternatively, "reverse_bits", or something like that.

Anyway, the implementation in this pull request is terrible; see http://graphics.stanford.edu/~seander/bithacks.html#ReverseParallel for the proper way to do it.

[alexcrichton]

@bill-myers, please keep the third point of our code of conduct in mind. Blatant insults will not be tolerated.

[lucab]

@bill-myers yes, it is a naïve O(n) implementation and it would as well make sense to move to a logarithmic one, trading a bit of clarity/simpllcity. However, as said, I have some other doubts about this PR and it may as well end being scrapped, so it's raw and far from being final.

[alexcrichton]

How about naming the method bitswap, tagging it #[experimental], and refactoring the implementation to have one shared (but private) function?

[alexcrichton]

Closing due to inactivity, but feel free to reopen with a rebase!