Date: Tue, 7 Jul 2026 14:53:40 -0400
Tom's P3311R0 proposed using a macro to control it, while P3290R0 proposed
making it implementation defined.
SG21 discussed and had consensus for Tom's design for the assert
integration. The minutes don't have what seems to be a huge amount of
discussion on particular reasons for the poll, but the poll was taken on
this exact decision.
EWG had consensus to forward P3290 with that design. I believe consistency
with how C allows other control of assert (through defining or not defining
NDEBUG) is the motivating reason. Given a general attitude many people
have of continuously throwing out FUD because "Contracts has too much
implementation-defined behavior" I do not believe there would be meaningful
consensus to pursuing the original P3290 design, though I myself am
relatively indifferent on that subject.
I suspect SG22, the group discussing this particular topic next, is likely
to want to keep things controlled by macros as that is how everything else
in C is controlled, but I obviously can't speak for that entire group.
Both alternatives are obviously fairly trivial to implement. (Though in
fairness, what a command-line flag would get you is a compiler-provided
predefined macro like __gcc_assert_uses_contracts or somethign similar that
was then used to control what assert expands to within assert.h --- the
primary difference being that the specific spelling of that macro would not
be standardized. It's also likely that both libc++ and libstdc++ would
recognize gcc and clang's predefined macros for this purpose so that you
get the desired behavior with either standard library on either compiler.)
On Tue, Jul 7, 2026 at 1:41 PM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:
> On Tue, 7 Jul 2026 at 20:38, Joshua Berne <berne_at_[hidden]> wrote:
> >
> >
> >
> > On Tue, Jul 7, 2026 at 1:33 PM Ville Voutilainen <
> ville.voutilainen_at_[hidden]> wrote:
> >>
> >> On Tue, 7 Jul 2026 at 20:15, Joshua Berne via Liaison
> >> <liaison_at_[hidden]> wrote:
> >> >
> >> > Thanks. I'm going to actually update the paper to change the
> proposed control macro to __STDC_WANT_ASSERT_USES_CONTRACTS__, with
> rationale and precedent. (The paper and compiler explorer will both be
> updated some time tonight).
> >> >
> >> > It would be good to get SG22 to poll on that macro name (or similar
> alternative) as input into the eventual LEWG discussion on the topic.
> >>
> >> What paper explains the rationale for relying on this macro, as
> >> opposed to, say, leaving the choice of whether assert() invokes a
> >> contract
> >> violation handler implementation-defined?
> >
> >
> > The paper that is on the agenda for discussion in this telecon, P3290?
> >
> > A topic that was also discussed and explicitly polled when R0 was
> presented in SG21 in St. Louis.
> >
> > You can find the current draft (which i linked to on this thread) here:
> https://isocpp.org/files/papers/D3290R5.pdf (Although I haven't uploaded
> the changed control macro yet).
>
> Right. I see no pros/cons analysis of my question in the paper. None
> of its revisions seem to justify relying on a new standardized macro
> from now to the end of time.
>
making it implementation defined.
SG21 discussed and had consensus for Tom's design for the assert
integration. The minutes don't have what seems to be a huge amount of
discussion on particular reasons for the poll, but the poll was taken on
this exact decision.
EWG had consensus to forward P3290 with that design. I believe consistency
with how C allows other control of assert (through defining or not defining
NDEBUG) is the motivating reason. Given a general attitude many people
have of continuously throwing out FUD because "Contracts has too much
implementation-defined behavior" I do not believe there would be meaningful
consensus to pursuing the original P3290 design, though I myself am
relatively indifferent on that subject.
I suspect SG22, the group discussing this particular topic next, is likely
to want to keep things controlled by macros as that is how everything else
in C is controlled, but I obviously can't speak for that entire group.
Both alternatives are obviously fairly trivial to implement. (Though in
fairness, what a command-line flag would get you is a compiler-provided
predefined macro like __gcc_assert_uses_contracts or somethign similar that
was then used to control what assert expands to within assert.h --- the
primary difference being that the specific spelling of that macro would not
be standardized. It's also likely that both libc++ and libstdc++ would
recognize gcc and clang's predefined macros for this purpose so that you
get the desired behavior with either standard library on either compiler.)
On Tue, Jul 7, 2026 at 1:41 PM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:
> On Tue, 7 Jul 2026 at 20:38, Joshua Berne <berne_at_[hidden]> wrote:
> >
> >
> >
> > On Tue, Jul 7, 2026 at 1:33 PM Ville Voutilainen <
> ville.voutilainen_at_[hidden]> wrote:
> >>
> >> On Tue, 7 Jul 2026 at 20:15, Joshua Berne via Liaison
> >> <liaison_at_[hidden]> wrote:
> >> >
> >> > Thanks. I'm going to actually update the paper to change the
> proposed control macro to __STDC_WANT_ASSERT_USES_CONTRACTS__, with
> rationale and precedent. (The paper and compiler explorer will both be
> updated some time tonight).
> >> >
> >> > It would be good to get SG22 to poll on that macro name (or similar
> alternative) as input into the eventual LEWG discussion on the topic.
> >>
> >> What paper explains the rationale for relying on this macro, as
> >> opposed to, say, leaving the choice of whether assert() invokes a
> >> contract
> >> violation handler implementation-defined?
> >
> >
> > The paper that is on the agenda for discussion in this telecon, P3290?
> >
> > A topic that was also discussed and explicitly polled when R0 was
> presented in SG21 in St. Louis.
> >
> > You can find the current draft (which i linked to on this thread) here:
> https://isocpp.org/files/papers/D3290R5.pdf (Although I haven't uploaded
> the changed control macro yet).
>
> Right. I see no pros/cons analysis of my question in the paper. None
> of its revisions seem to justify relying on a new standardized macro
> from now to the end of time.
>
Received on 2026-07-07 18:53:55
