Hi Jan,

On 2026-02-19T16:36:24+0100, Jan Schultke wrote:
> On Thu, 19 Feb 2026 at 16:27, Alejandro Colomar <
> une+cxx_std-proposals_at_[hidden]> wrote:
>
> > Hi Jan,
> >
> > On 2026-02-19T16:03:26+0100, Jan Schultke via Std-Proposals wrote:
> > > What OP proposes could also be done separately from static analysis as a
> > > compiler flag that requires the compiler to prove all contracts hold.
> > This
> > > essentially turns contract_assert into OP's compile_assert when the
> > > semantic is ignore. In any case, I think contracts are the right way to
> > > express conditions that should hold.
> >
> > I think contracts would have been less necessary with this feature.
> > And in C, we certainly don't want contracts, while this API would be
> > very nice.
> >
>
> Well, there are some WG14 papers dealing with contracts. Never say never,
> right?

I'm aware of them. And I hate them; it's horrible.

> Also, I don't think that having this feature would have made contracts less
> necessary. None of the current contract evaluation semantics do what OP is
> asking for. However, it would be possible to add a fifth "proof" contract
> evaluation semantic, one step up from ignore. That makes it seem to me like
> what OP proposes provides additional motivation for contracts in their
> current state, since our C++26 design could be extended to provide
> everything OP is asking for.
>
>
> > You can implement "contracts" by wrapping functions in macros, and using
> > this API to enforce conditions.
> >
>
> Contracts can do a lot more. Notably, they let you specify function
> contracts on declarations, not just in the body.

That's essentially the same as:

 int foo(int x);

 #define foo(x) \
 ({ \
  compiler_assert(...); // contract \
  foo(x); \
 })

Instead of writing a macro, you write a contract. I prefer the simpler
code in a macro.


Cheers,
Alex

> That would interoperate
> excellently with what OP proposes.

-- 
<https://www.alejandro-colomar.es>