Date: Tue, 3 Mar 2026 13:10:34 +0100
wt., 3 mar 2026 o 12:57 Jonathan Grant <jg_at_[hidden]> napisał(a):
>
>
>
> On 03/03/2026 11:19, Marcin Jaczewski wrote:
> > 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.
>
> Hi Marcin
>
> Ok I see, so the caller() call fail with a compile error if static analysis finds it's x is >= 10 before the call to foo(x)?
> then caller() can also static analysis check return z < x. These would force both functions to put checks that their values are within bounds and handle it safely I expect?
>
Close, right now it's only runtime checks but it can have enough
information that some compile checks
can be done.
> I wrote out below, where I show the lines the programmer needed to add:
>
> size_t foo(size_t x)
> {
> size_t result = get_network(x);
>
> // this line added to satisfy build constraint.
> if(result >= x) throw std::runtime_error;
> return result;
> }
>
> void caller()
> {
> size_t x = get_val();
>
> // this line added to pass constraint.
> if(x >= 10) throw std::runtime_error;
>
> size_t z = foo(x);
>
> std::cout << z;
> }
>
Yes, we could require that the programmer have explicit checks for
this too, but `get_val` has some
constraints on its return value that would make this check not needed,
but if the function has
changed (like return bigger range) then the compiler could fail to compile it.
I think we could require the compiler to do basic folding like `x <
10` and `z < x` and conclude that
`z < 10`.
> Regards
> Jonathan
>
>
>
>
> On 03/03/2026 11:19, Marcin Jaczewski wrote:
> > 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.
>
> Hi Marcin
>
> Ok I see, so the caller() call fail with a compile error if static analysis finds it's x is >= 10 before the call to foo(x)?
> then caller() can also static analysis check return z < x. These would force both functions to put checks that their values are within bounds and handle it safely I expect?
>
Close, right now it's only runtime checks but it can have enough
information that some compile checks
can be done.
> I wrote out below, where I show the lines the programmer needed to add:
>
> size_t foo(size_t x)
> {
> size_t result = get_network(x);
>
> // this line added to satisfy build constraint.
> if(result >= x) throw std::runtime_error;
> return result;
> }
>
> void caller()
> {
> size_t x = get_val();
>
> // this line added to pass constraint.
> if(x >= 10) throw std::runtime_error;
>
> size_t z = foo(x);
>
> std::cout << z;
> }
>
Yes, we could require that the programmer have explicit checks for
this too, but `get_val` has some
constraints on its return value that would make this check not needed,
but if the function has
changed (like return bigger range) then the compiler could fail to compile it.
I think we could require the compiler to do basic folding like `x <
10` and `z < x` and conclude that
`z < 10`.
> Regards
> Jonathan
>
Received on 2026-03-03 12:10:52
