If you think that's good, then you're gonna love this "simplified" real code posted as a real issue on one of my Github repos.
Edit: updated link to address the stack-trace comment
Since all of the expressions just wrap a
None
, I wouldn't be surprised if the transmutes basically get compiled to0
, making the assertion at the endassert_eq!(0 * 0, 0)
.Nah these are the actual integer representations. Otherwise you would have
Some(None) == Some(Some(None))
which is way too Javascripty for Rust folks.That's kind of wild, I double-checked and it's true.
Although I disagree with the second part, the Rust folks wouldn't care about the in-memory representation as long as the compilation is on point.
Looking closer at the final enum, I guess it's because there are nine possible cases for it, making the compiler pack it into 4 bits, with one number representing each? I checked and
None
is represented as8
, while 7Some
s containing aNone
is 0 and the full 8Some
s is represented by1
.the Rust folks wouldn’t care about the in-memory representation as long as the compilation is on point.
Well I can't speak for everyone, but Rust is very intentional about supporting things like
repr(C)
. At least some of us care a lot.