On Sun, 22 Feb 2026 at 13:33, Alejandro Colomar <
une+cxx_std-proposals_at_[hidden]> wrote:

> Hi Jonathan,
>
> On 2026-02-22T12:35:15+0000, Jonathan Wakely via Std-Proposals wrote:
> > Yes, I think "make it ill-formed at compile-time when optimizing,
> otherwise
> > add a runtime assertion" would be something people want to do.
> >
> > With the current proposal, that's awkward. You would need to do:
> >
> > #ifdef __OPTIMIZING__ && __ENABLE_COMPILE_ASSERT__
> > compile_assert(cond);
> > #else
> > assert(cond);
> > #endif
> >
> > or wrap that into your own macro. But that depends on a non-standard
> macro
> > which is compiler-dependent. It would be easier if the feature defined
> > something that you could check to see if the compile_assert is actually
> > enabled.
>
> I think what you called awkward would actually be great. Programmers
> would be free to choose the behavior they want from first principles.
> compiler_assert() would be a first principle. Feature test macros for
> these things are a higher level feature.
>

How is "you have to make your macro depend on GCC's __OPTIMIZING__ macro"
an advantage?

What if the implementation of compile_assert changes to not depend on
__OPTIMIZING__, wouldn't that make your macro incorrect because it would
not match the conditions used for compile_assert?




>
> > Also, the more I look at code examples using this, the less I like the
> > name. It didn't tell me what it does. All assertions are compiled, what
> is
> > a "compile assert"? Assert that something compiles, i.e. is syntactically
> > valid? That's what a requires expression does, but it's not what this
> does.
>
> I call this compiler_assert(), which I think is a better name.
>

I don't think that describes what it does either.