Open Seelengrab opened 1 year ago
With some more thought on this, I've come to the conclusion that 3. is not going to work, because I'd like this to still work even if the padding bits change out under the guarantees provided by the constructors. The use case motivating this is bits with undefined values of microcontroller/hardware registers.
Currently,
==
andhash
both just use the plain-bits, even if those contain padding bits (which have undefined value). This has the sideeffect of making two objects whose fields are equal unequal if their padding bits differ (which shouldn't matter). There are three possible paths:1 has the advantage of being likely faster & easier to implement, while 2. is likely more correct, as it doesn't make us observe padding bits. 3. could be difficult to guarantee.