Background: I was dealing with a bug in the project citybound, there was an bug where the program would crash in release mode, but was fine in debug mode. It took a bit of work getting things down to a minimal example, but eventually we found the issue. In the end it turned out that a null pointer was being passed to std::slice::from_raw_parts, which is against that functions contract, even if the given length is 0. My understanding is that never passing null enables some optimization. I found this to be a subtle bug for someone who is new to the citybound project. Consider that the person who wrote the code calling from_raw_parts (and read its docs) might not be the same person debugging that part of the code, and it isn’t obvious from the function name or signature that passing null pointers along with 0 length is UB.
Although at the moment it is UB to pass null into this function, it would more helpful for debug builds to assert that p is not null. This way it would emit a useful error message. I understand that half UB might be undesirable, in which case might might be useful instead to have a tool that detects UB, even if it is at runtime (al la UBSan).
The citybound bug in question is here, but the more relevant discussion starts here.
My recollection is that there are a bunch of places where std would like to add additional checks like this, but that currently the same std library is used for both debug and release, and thus debug_assert is never there in stable (only if you enable them in config.toml in a custom build).
debug assertions generally are meant to reduce the final binary’s amount of machine code (and thus improve the performance). We could stop using cfg to achieve this feature and instead rely on const propagation and a “magical” MIR constant that can be flipped without requiring a recompilation of the function. Compiling the MIR to machine code would then eliminate the branch depending on the value of the flippable constant.