Il 20/02/26 00:07, Brian Bi via Std-Proposals ha scritto:
> Therefore, there is a strong argument for banning this feature
> organization-wide if it were to become part of the standard.

While the idea is clever, I share very similar concerns about
standardizing this. I'd like this to be field-tested and deployed at
scale, before being comfortable with it.

The interactions with contracts are certainly something to research, in
the sense that contracts are taking useful space as generic function
"preamble" and "postamble" ; one may entertain the idea to put a
compile_assert on the return value of a function and a post() seems the
right place to do it.

I'm also concerned by the fact that this depends on compiler vendor,
compiler version, and enabled optimization levels, which is going to
effectively make it impossible to adopt by libraries that need to be
portable. Even if one sticks to one compiler vendor, what happens if
that compiler regresses an optimization pass and assertions that used to
pass start to spuriously fail? I'm not particularly optimistic --
middle-end regressions may stay unsolved for years.

Finally, I'm afraid that if I place a compile_assert() into some library
function of mine, and it fires for some users, then they might just end
up adding an [[assume()]] to make the compiler shut up and stop
complaining, instead of doing the necessary refactorings etc. in order
to help the optimizer, thereby defeating the purpose of this feature.

My 2 c,
--
Giuseppe D'Angelo