<div dir="ltr">The trac issue this is asking about is found here: <a href="https://ghc.haskell.org/trac/ghc/ticket/14839">https://ghc.haskell.org/trac/ghc/ticket/14839</a>. I'm looking for any feedback from the broader community to see if the proposed law is incompatible with any important uses of Bits. The text of the trac issue is provided below:<div><br>The documentation for the Bits typeclass claims:<br><br>    Bits are numbered from 0 with bit 0 being the least significant bit.<br><br>However, there's no law specified in the typeclass that enforces this. I realized this recently because I've been adding the laws for Bits to a library of property tests I maintain: <a href="http://hackage.haskell.org/package/quickcheck-classes-0.3.3/docs/Test-QuickCheck-Classes.html#v:bitsLaws">http://hackage.haskell.org/package/quickcheck-classes-0.3.3/docs/Test-QuickCheck-Classes.html#v:bitsLaws</a><br><br>In another package of mine, someone requested to add a Bits instance for a type but with the MSB considered bit 0. (<a href="https://github.com/andrewthad/haskell-ip/issues/29">https://github.com/andrewthad/haskell-ip/issues/29</a>) I thought this would fail to satisfy a law of Bits, but it doesn't. So at the least, I was thinking we could add the following laws to FiniteBits:<br class="gmail-Apple-interchange-newline"><br>    countTrailingZeros (bit 0) = 0<br>    countLeadingZeros (bit 0) = finiteBitSize undefined - 1<br><br><div>-- <br><div class="gmail_signature">-Andrew Thaddeus Martin</div>
</div></div></div>