Reverse the generic parameter order to make the type shorter

[changhe3]

I know this is trivial and will break every dependent code base, but if there were to be a "new edition", please consider to put the storage class parameter before the bit order parameter in types like BitSlice, BitArray and BitVec. In most cases, the bit order parameter is rared changed, and people would use either Lsb0 or LocalBits everywhere, whereas people change the bit storage parameter in different places all the time for optimal memory usage/access and the default usize is unnecessarily big/inflexible for many applications.

By switching the order around, users would only need to write BitSlice<u8> instead of BitSlice<Lsb0, u8>.

[gabhijit]

Can you not simply use BitSlice<_, u8> ?

[myrrlyn]

I am currently working to a 1.0 release, and am already intending to cause API breakage in the update. I believe you have a point, and I will give switching them a try and see how I feel about it.

Honestly, the ordering was chosen arbitrarily, and I've just gotten accustomed to it, but I don't have any actual rationale for or against <O, T> vs <T, O>.

However, we have these examples in the standard library:

• HashMap<K, V, S> has always existed, and I should have consulted it. The S parameter rarely changes, and is almost always used as the default.
• Box<T, A> and Vec<T, A> are new APIs. Like HashMap, the A rarely changes and not only is almost always the default, but has to be placed at the back in order for code that was written before its addition to continue to operate.

[myrrlyn]

Okay I've gone through and made the change locally. It was nightmarish to accomplish but now that I did, I am forced to admit it's better. It's more consistent with common bit-slice init patterns (like EXPRusize.view_bits::<Lsb0>()), it simplified most of my half-formed types, and it matches existing behavior.

This change will likely be present in 1.0. I'll leave this issue open until then in case arguments against doing so (other than "this is a major breaking change") emerge, but I will lock this issue once I publish 1.0, because I'm linking to it in the documentation and I don't want to risk swarming your notifications.

Thank you for the issue; I apologize for my radio silence.

[myrrlyn]

Wrong button. This will close when 1.0 publishes.

[flying-sheep]

which it did now