wt., 3 mar 2026 o 11:41 Jonathan Grant <jg_at_[hidden]> napisał(a):
>
>
> > 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().
>

I mean THE C++ preconditions like:

```
size_t foo(size_t x) pre(x < 10) post(z: z < x);
```

as you see no function body posted there but you know that result will
be less than given x.
We could ask the compiler to solve them statically and the programmer
can add more constatians
to make it possible for dumb compiler. No need for optimization levels
only constexpr calcations.

> Thank you for the feedback.
> Jonathan