Date: Tue, 3 Mar 2026 11:05:58 +0000
On 20/02/2026 11:27, Sebastian Wittmeier via Std-Proposals wrote:
> Can this feature proposal be lifted from a best-effort base to be reproducible?
I think optimizers are just opportunistic, dependent upon the compiler settings as I understand it.
> Something like preconditions contracts, which have to be provably be true at compile-time.
>
> Can there be hints to guide the compiler to a deterministic proof?
I'm not sure, if we put something in like [[assume]] or unreachable, it might fail to identify real cases. I'd need to investigate more.
May I ask, re the best-effort basis. It could be if an optimizer is running slowly it gives up. Although GCC seems to get all the simple compile_assert() I add. Maybe I don't need to worry.
It feels better I just define the syntax of the keyword, and then a weak compiler may not be able to fathom all code paths, so those programmers wouldn't be able to put in as many compile_assert()
Deterministic proofs are difficult a some code base is open ended.
May I ask an unrelated question:
If my compile_assert constraint is satisfied (ie index to access a buffer is within bounds), it will compile out. But if the constraint required a bounds check on an array access index - do you think the compiler could later remove that bounds check? Because now the compile_assert itself compiled out, and the linker, or LTO could come along, collect all those obj files and remove my array index check, take away my safety pattern. I don't want it to silently evaporate.
Regards
Jonathan
> Can this feature proposal be lifted from a best-effort base to be reproducible?
I think optimizers are just opportunistic, dependent upon the compiler settings as I understand it.
> Something like preconditions contracts, which have to be provably be true at compile-time.
>
> Can there be hints to guide the compiler to a deterministic proof?
I'm not sure, if we put something in like [[assume]] or unreachable, it might fail to identify real cases. I'd need to investigate more.
May I ask, re the best-effort basis. It could be if an optimizer is running slowly it gives up. Although GCC seems to get all the simple compile_assert() I add. Maybe I don't need to worry.
It feels better I just define the syntax of the keyword, and then a weak compiler may not be able to fathom all code paths, so those programmers wouldn't be able to put in as many compile_assert()
Deterministic proofs are difficult a some code base is open ended.
May I ask an unrelated question:
If my compile_assert constraint is satisfied (ie index to access a buffer is within bounds), it will compile out. But if the constraint required a bounds check on an array access index - do you think the compiler could later remove that bounds check? Because now the compile_assert itself compiled out, and the linker, or LTO could come along, collect all those obj files and remove my array index check, take away my safety pattern. I don't want it to silently evaporate.
Regards
Jonathan
Received on 2026-03-03 11:06:06