C++ Logo

liaison

Advanced search

Re: [isocpp-wg14/wg21-liaison] INVITE: SG22 Telecon 2026-07-08 04:30 PM UTC

From: Ville Voutilainen <ville.voutilainen_at_[hidden]>
Date: Tue, 7 Jul 2026 21:57:23 +0300
On Tue, 7 Jul 2026 at 21:53, Joshua Berne <berne_at_[hidden]> wrote:
>
> 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.)

So there's no paper that explains the rationale for this choice?

Received on 2026-07-07 18:57:38