Date: Tue, 3 Mar 2026 10:41:33 +0000
> On Sun, 22 Feb 2026, 11:26 Marcin Jaczewski via Std-Proposals, <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
>
<....>>
> Beside preconditions are visible on both sides of function call even if not
> inlined, this means you do not need to rely on opimalzier to do this job
> as you put enough preconditions to make all checks local.
Martin may I ask, re inlining, if a function has an attribute [[gnu::noinline]] in my tests I found the constant is not propagated, so the Optimizer fails to identify the constraint is met. Is there any solution?
[[gnu::noinline]]
int get_int() { return 10; }
int x = get_int();
compile_assert(x < 15, "x must be < 15");
If I changed the compile_assert() to call a [[deprecated]] function, the obj file would be produced, but it would then rely upon the linker removing the compile_assert() still there.
There may be some places where it's difficult to place a compile_assert().
Thank you for the feedback.
Jonathan
>
<....>>
> Beside preconditions are visible on both sides of function call even if not
> inlined, this means you do not need to rely on opimalzier to do this job
> as you put enough preconditions to make all checks local.
Martin may I ask, re inlining, if a function has an attribute [[gnu::noinline]] in my tests I found the constant is not propagated, so the Optimizer fails to identify the constraint is met. Is there any solution?
[[gnu::noinline]]
int get_int() { return 10; }
int x = get_int();
compile_assert(x < 15, "x must be < 15");
If I changed the compile_assert() to call a [[deprecated]] function, the obj file would be produced, but it would then rely upon the linker removing the compile_assert() still there.
There may be some places where it's difficult to place a compile_assert().
Thank you for the feedback.
Jonathan
Received on 2026-03-03 10:41:38
