The compiler should emit a warning at compilation time, when it decided to replace the conditional with single branch, throwing away the condition itself and the second branch.

If I wrote some code, I expect it to be present in the binary. I don't just write code to be removed by the compiler. If that expectation was wrong, compiler should inform me about that.

How about if the compiler translates a pointer deference into a read of that memory address? That is potential undefined behaviour that has been "optimised" into something simpler than a safe operation (tracking all memory allocations and checking if the pointer is correctly pointing into one of them). So every pointer deference would also generate a warning (except perhaps where the compiler can prove from local information that it's safe).

It is definitely a hopeless path.

> If I wrote some code, I expect it to be present in the binary.

That's oversimplified. If after inlining and constant folding an if-condition turns out to be always true or false I would definitely expect that the compiler removes the dead branch.

This type of optimization is the base for the fabled "zero-cost-abstraction" (which isn't only a C++ thing, C code depends on it just as much), and removing those optimization would seriously tank peformance in any non-trivial codebase.

> If I wrote some code, I expect it to be present in the binary. I don't just write code to be removed by the compiler.

It's very common to write code in templates or inline functions expecting the compiler to remove it if it's not relevant on the calling site. That's part of what makes "zero cost abstractions" have zero cost at runtime.

For instance, I have a SIMD routine with extra code to process the tail (leftover elements smaller than the native vector size). When the compiler can prove that the size of the input will always be a multiple of the vector size (which is very common for my use cases), it will completely remove that tail handling code.