Hi Jonathan,

On 2026-02-22T14:03:49+0000, Jonathan Wakely wrote:
> On Sun, 22 Feb 2026 at 13:33, Alejandro Colomar <
> une+cxx_std-proposals_at_[hidden]> wrote:
> > 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?

I would specify and implement compiler_assert() to not depend on
__OPTIMIZING__ at all. Make it just the bare minimum:

 #define compiler_assert(e) do \
 { \
  [[gnu::error("")]] extern void fail_(void); \
               \
  if (!(e)) \
   fail_(); \
 } while (0)

And then let users build on top of that.

> > > 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.

Yeah, I'm not too happy about it, but I prefer it over compile_assert().


Cheers,
Alex

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