Date: Fri, 27 Feb 2026 14:12:03 +0000
On 22/02/2026 08:24, Jonathan Wakely wrote:
>
>
> On Sun, 22 Feb 2026, 03:29 Jonathan Grant via Std-Proposals, <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
>
> Following on from my email thread, I am sharing a draft of my compile_assert proposal as a PDF below.
>
> https://github.com/jonnygrant/compile_assert/blob/main/proposal/compile_assert__isocpp__PnnnnR0.pdf <https://github.com/jonnygrant/compile_assert/blob/main/proposal/compile_assert__isocpp__PnnnnR0.pdf>
>
> Is there anything people would like to see, what would be useful to add?
>
> I've put a call out for small 'tricky' examples I can try below.
>
> I appreciate all the discussion so far.
> I've added detail to my draft to cover some of issues raised. ie relying on optimizer, making code backwards compatible so compile_assert completely compiles out if the feature is not enabled on a particular compiler.
>
>
>
>
> Abstract
>
> Following the recent mailing list discussion of my 2023 compile_assert() proposal, this paper introduces compile_assert(expression, message), a new C++ keyword
>
>
> The proposal is for a macro not a keyword, so this abstract (which isn't the abstract from the PDF) is misleading.
>
You're absolutely right - the wording was ambiguous, so I've edited the draft to clarify as a keyword.
At the moment compile_assert is implemented as a macro in my sample. However, static_assert() started as a macro then became a keyword.
My intention is simply to describe the syntax of compile_assert as a proposed core language feature. If compile_assert gains some wider adoption, becomes popular, it would be worth formalizing as a C++ keyword.
> The proposal talks about adding _Compile_assert but that doesn't seem necessary or desirable (that's how features are added in C, not in C++).
>
That makes sense, I removed that from the draft I am editing.
Is it okay to share my proposal working copy edit link here?
I've also added another compiler support, MSVC.
> The proposal doesn't mention that virtually all code using it must be inline functions or function templates, or have internal linkage, because if a function that uses the macro is not completely optimized away, it will refer to the function with the error attribute and that's ill-formed.
>
That's a good point, I need to draw attention that functions need to be in an anonymous namespace or static, I've added that to my working draft.
> The proposal doesn't mention that the error attribute is non-standard. Do all compilers even support something like that? How would this be implemented on compilers that don't support that GCC feature?
The way I do with MSVC is a deliberately missing symbol triggering an error, so the linker fails. I embed the file and line number in the so the diagnostic shows the exact location compile_assert expression failed.
There is a C++14 standard [[deprecated(message)]] Alejandro Colomar suggested. I could move to using that, however the advantage of attribute error(message) is it's been around for a long time hopefully all gcc users have it available if they're not on C++14 yet.
For compilers that do not support the gcc error attribute approach - asm("stopbuild") (this works with gcc). MSVC 64bit removed __asm() unfortunately.
>
> All the examples are trivial. Can you show it being used in larger codebases? Even an example with more than one translation unit would be more interesting than just 16 different main() functions. Most applications consist of more than main() and one or two static functions in the same translation unit.
That's a good point. I use on multi file projects. But as you say, it's more interesting evaluating an idea if it works across different files. I'll add that to my list of things to improve.
There is a two file example showing how an API can be checked (forces change on to the calling code)
https://github.com/jonnygrant/compile_assert/tree/main/main13
I appreciate all the discussion.
Regards
Jonathan
>
>
>
> for enforcing assertions at compile time within ordinary (non-constexpr) functions.
>
>
> I'm also particularly interested in any feedback from anyone who is using compile_assert() to detect issues in all C/C++ software, and in particular safety critical systems, automotive, aviation, medical etc.
>
> Also interested if anyone would like to share more simple examples where it has been beneficial. Of course if you have any tricky examples, please do share them with me, I'll try find a way to get them to be checked by compile_assert()
>
> Any feedback about the draft will be really appreciated!
>
> Jonathan
>
>
>
> On Sun, 22 Feb 2026, 03:29 Jonathan Grant via Std-Proposals, <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
>
> Following on from my email thread, I am sharing a draft of my compile_assert proposal as a PDF below.
>
> https://github.com/jonnygrant/compile_assert/blob/main/proposal/compile_assert__isocpp__PnnnnR0.pdf <https://github.com/jonnygrant/compile_assert/blob/main/proposal/compile_assert__isocpp__PnnnnR0.pdf>
>
> Is there anything people would like to see, what would be useful to add?
>
> I've put a call out for small 'tricky' examples I can try below.
>
> I appreciate all the discussion so far.
> I've added detail to my draft to cover some of issues raised. ie relying on optimizer, making code backwards compatible so compile_assert completely compiles out if the feature is not enabled on a particular compiler.
>
>
>
>
> Abstract
>
> Following the recent mailing list discussion of my 2023 compile_assert() proposal, this paper introduces compile_assert(expression, message), a new C++ keyword
>
>
> The proposal is for a macro not a keyword, so this abstract (which isn't the abstract from the PDF) is misleading.
>
You're absolutely right - the wording was ambiguous, so I've edited the draft to clarify as a keyword.
At the moment compile_assert is implemented as a macro in my sample. However, static_assert() started as a macro then became a keyword.
My intention is simply to describe the syntax of compile_assert as a proposed core language feature. If compile_assert gains some wider adoption, becomes popular, it would be worth formalizing as a C++ keyword.
> The proposal talks about adding _Compile_assert but that doesn't seem necessary or desirable (that's how features are added in C, not in C++).
>
That makes sense, I removed that from the draft I am editing.
Is it okay to share my proposal working copy edit link here?
I've also added another compiler support, MSVC.
> The proposal doesn't mention that virtually all code using it must be inline functions or function templates, or have internal linkage, because if a function that uses the macro is not completely optimized away, it will refer to the function with the error attribute and that's ill-formed.
>
That's a good point, I need to draw attention that functions need to be in an anonymous namespace or static, I've added that to my working draft.
> The proposal doesn't mention that the error attribute is non-standard. Do all compilers even support something like that? How would this be implemented on compilers that don't support that GCC feature?
The way I do with MSVC is a deliberately missing symbol triggering an error, so the linker fails. I embed the file and line number in the so the diagnostic shows the exact location compile_assert expression failed.
There is a C++14 standard [[deprecated(message)]] Alejandro Colomar suggested. I could move to using that, however the advantage of attribute error(message) is it's been around for a long time hopefully all gcc users have it available if they're not on C++14 yet.
For compilers that do not support the gcc error attribute approach - asm("stopbuild") (this works with gcc). MSVC 64bit removed __asm() unfortunately.
>
> All the examples are trivial. Can you show it being used in larger codebases? Even an example with more than one translation unit would be more interesting than just 16 different main() functions. Most applications consist of more than main() and one or two static functions in the same translation unit.
That's a good point. I use on multi file projects. But as you say, it's more interesting evaluating an idea if it works across different files. I'll add that to my list of things to improve.
There is a two file example showing how an API can be checked (forces change on to the calling code)
https://github.com/jonnygrant/compile_assert/tree/main/main13
I appreciate all the discussion.
Regards
Jonathan
>
>
>
> for enforcing assertions at compile time within ordinary (non-constexpr) functions.
>
>
> I'm also particularly interested in any feedback from anyone who is using compile_assert() to detect issues in all C/C++ software, and in particular safety critical systems, automotive, aviation, medical etc.
>
> Also interested if anyone would like to share more simple examples where it has been beneficial. Of course if you have any tricky examples, please do share them with me, I'll try find a way to get them to be checked by compile_assert()
>
> Any feedback about the draft will be really appreciated!
>
> Jonathan
>
Received on 2026-02-27 14:12:09
