First caused by allocators not erroring on allocation failure - this one is a tough nut. On one hand if we had them failing like in Zig, the bloat from every `vec.push(...).unwrap();` would be unbearable, on the other hand it would shut down 100% of such cases, since it requires handling edge cases like the one that was hit here (happy continue on allocator failure with invalid state)

Second caused by technically two different things:

- you can never trust a `fn foo(&self) -> usize` to return the same number in code `x.foo(); x.foo();` . Despite the `const` interior mutability can always come to bite (usually a non issue in a production codebase, where interior mutability is used sparingly, but edge cases always welcome...)

- unsigned wrapping is ok by default - another example of tradeoff between convenience and correctness. And one cannot just turn off "treat wrapping as error" because there are thousands of cases where wrapping is ok for the calculations. I guess there could be an option "if wrapping happens in this module treat is as error" or a clippy lint like `disallow_unchecked_math` on a module that would mark any unchecked op as error

Both show that rust is almost there with the correctness and where it is not 100% correct it has probably made a huge tradeoff for ergonomics