I'm actually considering macroing our asserts right now, ahead of C++26, to
get a head start on future contracts (obviously only contract_assert and
not pre and post). Macros may be evil, but in some cases they are the
lesser evil.

Macroing means you may later want to rewrite that code once contracts catch
up to your needs. But how is that different from you wanting explicit
semantics specified in your contract assertions, which might also have to
be modified later as that code matures?


On Mon, Oct 27, 2025 at 8:19 PM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:

> On Mon, 27 Oct 2025 at 20:15, Andrei Zissu <andrziss_at_[hidden]> wrote:
> >
> >
> >
> > On Mon, Oct 27, 2025 at 8:02 PM Gabriel Dos Reis <gdr_at_[hidden]>
> wrote:
> >>
> >> [Ville]
> >> > It doesn't. The goal isn't to get some functionality as fast as
> >> > possible, but to get cohesive and correct functionality so that we
> >> > don't run into
> >> > a situation where programmers have unfortunate choices to make, and
> >> > then some need to deal with the support, review, policy and product
> >> > management consequences of those choices.
> >>
> >> 100%.
> >>
> >> Furthermore, WG21 voting something into a stack of papers does not
> magically make that thing spontaneously appear in your production compiler
> if said thing is ignored or seen as totally wacky.
> >
> >
> > Ignoring a major new language feature may prove disadvantageous for said
> compiler once competing ones start supporting it.
>
> It will result in some of us having to macro every single contract
> assertion that might ever enter our codebases, including some in code
> that
> we don't write but have to use. Even if that code is C++26-only.
>
> Not exactly the best use of development budgets, that.
>