On 20/02/2026 15:12, Giuseppe D'Angelo via Std-Proposals wrote:
> 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.

Thank you for your input Giuseppe. I'm grateful for your feedback, and Brian Bi above.

In the published proposal there is a macro, that is disabled unless a programmer enables it with __ENABLE_COMPILE_ASSERT__

>
> 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'd like to see C++ Contracts make use of information the Optimizer has about expressions that are determined to be const, or not (ie an index not in buffer bounds check!).

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

You're completely right, there could be different optimizations coming in to play, and if a high level of optimization was needed to 'pass' that locks in that level as required for ever that build is in use (let's hope no compiler regressions!).

Do you think it would be better programmers only enable compile_assert in their "lint" build to get the diagnostics?
One big advantage of compile_assert in gcc, clang and MSVC is that it's within the compiler that I am using for my release builds. If I rely upon clang-tidy for analysis, but then compile with MSVC I wouldn't feel as confident; ie lint-compiler-dogfooding better.

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

The way compile_assert() is now, if it is within a library and your library compiles successfully and links, there would not be any compile_assert symbol or residue of it. It would all compile out. If your library did not compile and link due to a failed compile_assert(expr), in that case there wouldn't be a library to deliver to a customer.

Unfortunately there are always workarounds to make compiler warnings quiet, maybe we just need to keep doing human code reviews? I'm not sure the best solution for that one.

Thank you again for the feedback.
Jonathan