C++26: A User-Friednly assert() macro

Putting code with side effects into an assert is asking for trouble. Compile with NDEBUG set and the effects mysteriously disappear! Anything beyond an equality expression or straight boolean should be avoided.

> (assert) doesn't follow the usual SCREAMING_SNAKE_CASE convention we associate with macros

There are a few things like that, for example:

https://en.cppreference.com/w/c/numeric/math/isnan - isnan is an implementation defined macro.

https://en.cppreference.com/w/c/io/fgetc - `getc` may be implemented as a macro, but often it's a function.

The nice thing about assert() is you can just define your own:

https://github.com/fiberfs/fiberfs/blob/7e79eaabbb180b0f1a79...

In this case, the ability to see the actual values that triggered the assert is way more helpful.

Friedns shouldn't let Freidns post on HN without running spell check

Shouldn't the preprocessor be fixed, if it trips that easily on common C++ constructs?

"C++47: Finally, a Standard Way to Split a String by Delimiter"

assert(spellcheck(“Friednly”));

> (assert) doesn't follow the usual SCREAMING_SNAKE_CASE convention we associate with macros

There are a few things like that, for example:

https://en.cppreference.com/w/c/numeric/math/isnan - isnan is an implementation defined macro.

https://en.cppreference.com/w/c/io/fgetc - `getc` may be implemented as a macro, but often it's a function.

The nice thing about assert() is you can just define your own:

https://github.com/fiberfs/fiberfs/blob/7e79eaabbb180b0f1a79...

In this case, the ability to see the actual values that triggered the assert is way more helpful.

Friedns shouldn't let Freidns post on HN without running spell check

"C++47: Finally, a Standard Way to Split a String by Delimiter"

I'm still waiting for C++ to support Unicode properly.

A standard way to split a string? Well, what's wrong with:

    std::views::split(my_string, delimeter)

?

I once spent several days debugging that same mistake. Stuff worked perfectly in tests but broke misteriously in production builds. Couldn't stop laughing for a few minutes when I finally figured it out.

Indeed.

   bool is_even(int* valPtr) {
      assert(valPtr != nullptr);
      return *valPtr % 2;
    }

Does not do what you think it does with nullptr. A major game engine [0] has a toggle to enable asserts in shipping builds, mostly for this reason

[0] https://dev.epicgames.com/documentation/en-us/unreal-engine/...

That's why you define your own assert macro and keep in on unconditionally. Your programs will be better for it.

This is just a symptom of a bad assert() implementation, which funny enough is the standard. If you properly (void) it out, side effects are maintained.

https://github.com/fiberfs/fiberfs/blob/7e79eaabbb180b0f1a79...

Side effects are bad of course, but anything beyond a straight boolean or equality is bad?

`assert(vector.size() < 3)` is ridiculous to you?

I don't mean to be that guy, but for "functional" programmers a print statement has "side effects".

But your meaning is clear. In an assert expression, don't call functions that might change the program/database state. Be as "const" as possible.

assert(spellcheck(“Friednly”));

Shouldn't the preprocessor be fixed, if it trips that easily on common C++ constructs?

  spellcheck.cpp:1:19: error: unexpected character <U+201C>
      1 | assert(spellcheck(“Friednly”));
        |                   ^

Preprocessor is just doing text transformations on the sources.

It's not really something that can be fixed, other than moving away from the preprocessor and putting metaprogramming capabilities into the language itself (which C++ has been doing).

I'm sure the standardization committee are always looking for fresh ideas!

I'm still waiting for C++ to support Unicode properly.

A standard way to split a string? Well, what's wrong with:

    std::views::split(my_string, delimeter)

?

Template bloat, terrible compile errors, terrible debug build performance, 1 second of extra compile time per cpp file when you include ranges, and you can't step through it in a debugger.

Side effects are bad of course, but anything beyond a straight boolean or equality is bad?

`assert(vector.size() < 3)` is ridiculous to you?

  spellcheck.cpp:1:19: error: unexpected character <U+201C>
      1 | assert(spellcheck(“Friednly”));
        |                   ^

That's why you define your own assert macro and keep in on unconditionally. Your programs will be better for it.

An assertion can be arbitrarily expensive to evaluate. This may be worth the cost in a debug build but not in a release build. If all of assertions are cheap, they likely are not checking nearly as much as they could or should.

Indeed.

   bool is_even(int* valPtr) {
      assert(valPtr != nullptr);
      return *valPtr % 2;
    }

Does not do what you think it does with nullptr. A major game engine [0] has a toggle to enable asserts in shipping builds, mostly for this reason

[0] https://dev.epicgames.com/documentation/en-us/unreal-engine/...

This is a very "Dr Dr it hurts when I do this" "Don't do that" one it must be said.

I'm sorry, but what exactly is the problem with the code? I've been staring at it for quite a while now and still don't see what is counterintuitive about it.

This is just a symptom of a bad assert() implementation, which funny enough is the standard. If you properly (void) it out, side effects are maintained.

https://github.com/fiberfs/fiberfs/blob/7e79eaabbb180b0f1a79...

I don't mean to be that guy, but for "functional" programmers a print statement has "side effects".

But your meaning is clear. In an assert expression, don't call functions that might change the program/database state. Be as "const" as possible.

assert() is meant to be compiled away if NDEBUG is defined, otherwise it shouldn't be called assert(). Given that assert() may be compiled away, it makes sense not to give it anything that has side effects.

Abseil has the convention where instead of assert(), users call "CHECK" for checks that are guaranteed to happen at run time, or "DCHECK" for checks that will be compiled away when NDEBUG is defined.

https://github.com/abseil/abseil-cpp/blob/0093ac6cac892086a6...

Not just for functional programmers. Prints and other I/O operations absolutely are side effects. That's not running counter to the point being made. Print in an assert and NDEBUG takes away that behavior.

Template bloat, terrible compile errors, terrible debug build performance, 1 second of extra compile time per cpp file when you include ranges, and you can't step through it in a debugger.

Possibly but I've never seen it in practice that some assert evaluation would be the first thing to optimize. Anyway should that happen then consider removing just that assert.

That being said being slow or fast is kinda moot point if the program is not correct. So my advisor to leave always all asserts in. Offensive programming.

This is a very "Dr Dr it hurts when I do this" "Don't do that" one it must be said.

I'm sorry, but what exactly is the problem with the code? I've been staring at it for quite a while now and still don't see what is counterintuitive about it.

There's nothing wrong with it. It does exactly what you think it does when passed null.

I'm sure the standardization committee are always looking for fresh ideas!

Preprocessor is just doing text transformations on the sources.

It's not really something that can be fixed, other than moving away from the preprocessor and putting metaprogramming capabilities into the language itself (which C++ has been doing).

I mean, you could extend it such that a simple comma has no special meaning.

But I agree, fewer special tricks is better and that includes the preprocessor.

Abseil has the convention where instead of assert(), users call "CHECK" for checks that are guaranteed to happen at run time, or "DCHECK" for checks that will be compiled away when NDEBUG is defined.

https://github.com/abseil/abseil-cpp/blob/0093ac6cac892086a6...

If your assert compiles down to `if (condition) {}` in production then the compiler will optimize away the condition while keeping any side effects.

Possibly but I've never seen it in practice that some assert evaluation would be the first thing to optimize. Anyway should that happen then consider removing just that assert.

That being said being slow or fast is kinda moot point if the program is not correct. So my advisor to leave always all asserts in. Offensive programming.

There's nothing wrong with it. It does exactly what you think it does when passed null.

I mean, you could extend it such that a simple comma has no special meaning.

But I agree, fewer special tricks is better and that includes the preprocessor.

If your assert compiles down to `if (condition) {}` in production then the compiler will optimize away the condition while keeping any side effects.

C++26 is bringing some long-overdue changes to assert(). But why are those changes needed? And when do we actually use assert, anyway?

At its core, assert() exists to validate runtime conditions. If the given expression evaluates to false, the program aborts. I’m almost certain you’ve used it before — at work, in personal projects, or at the very least in examples and code snippets.

So what’s the problem?

The macro nobody treats like a macro

assert() is a macro — and a slightly sneaky one at that. Its name is written in lowercase, so it doesn’t follow the usual SCREAMING_SNAKE_CASE convention we associate with macros. There’s a good chance you’ve been using it for years without ever thinking about its macro nature.

Macros, of course, aren’t particularly popular among modern C++ developers. But the issue here isn’t the usual - but valid - “macros are evil” argument. The real problem is more specific:

The preprocessor only understands parentheses for grouping. It does not understand other C++ syntax such as template angle brackets or brace-initialization.

As a result, several otherwise perfectly valid-looking assertions fail to compile:

<table><tbody><tr><td><pre>1 2 3 4 5 6 7 </pre></td><td><pre>// https://godbolt.org/z/9sqM7PvWh using Int = int; int x = 1, y = 2; assert(std::is_same<int, Int>::value); assert([x, y]() { return x < y; }() == 1); assert(std::vector<int>{1, 2, 3}.size() == 3); </pre></td></tr></tbody></table>

Each of these breaks for essentially the same reason: the macro argument parsing gets confused by commas or braces that aren’t wrapped in an extra pair of parentheses.

You can fix each of them, of course, by adding an extra pair of parentheses. For example the last assertion would become assert((std::vector<int>{1, 2, 3}.size() == 3)); - you can play with the examples here.

But let’s be honest: this is ugly, easy to forget, and not exactly beginner-friendly. Sure, after hitting the problem once or twice, most people internalize the workaround — just like with the most vexing parse. Still, it’s unnecessary friction for such a fundamental utility.

P2264R7: Making `assert` less fragile

This is where Peter Sommerlad’s proposal, P2264R7, comes in.

The proposal fixes the assert macro by redefining it as a variadic macro using __VA_ARGS__. Instead of accepting a single parenthesized expression, assert now takes (...) as its parameter. That small change makes all the previously broken examples just work — no extra parentheses required.

What about diagnostic messages?

Originally, the proposal allowed users to attach diagnostic text via the comma operator, similar to static_assert. That idea didn’t survive the review phase.

Instead, there is a mechanism to prevent the use of the comma operator on a top level, so you cannot accidentally create always true assertions like this:

<table><tbody><tr><td><pre>1 </pre></td><td><pre>assert(x > 0 , "x was not greater than zero"); </pre></td></tr></tbody></table>

Something that you could very easily create from an existing static_assert.

So if we want to have some diagnostics, we still have to use the && operator instead:

<table><tbody><tr><td><pre>1 </pre></td><td><pre>assert(x > 0 && "x was not greater than zero"); </pre></td></tr></tbody></table>

This keeps the semantics clear and avoids subtle bugs.

But aren’t contracts coming?

One common objection addressed in the proposal is the claim that assert is obsolete in a future with contracts.

Contracts will be great. But they won’t make assert disappear overnight.

Just as concepts didn’t eliminate SFINAE or older template techniques — they simply gave us better tools — contracts won’t erase assert either. Assertions will continue to exist in real-world codebases, whether directly or wrapped inside higher-level precondition utilities. Improving assert is still valuable, especially when the changes are small, simple, and easy to backport.

If you’re curious, the paper discusses several other potential concerns in detail; you can find them in the section on potential liabilities of the proposed change.

Compatibility and availability

Importantly, this change does not break existing code. All previously valid usage patterns remain valid — the proposal merely enables new, less fragile ones.

At the time of writing, (February 2026), none of the major compilers support this feature yet. As with many C++26 improvements, it will take some time before it becomes widely available.

Conclusion

The C++26 update to assert() is a great example of incremental language evolution done right. It doesn’t reinvent assertions, replace them with something flashier, or force new programming models on existing code. Instead, it quietly removes a long-standing sharp edge.

By making assert variadic, the language eliminates a class of surprising compilation failures, improves readability, and reduces the cognitive overhead of using a tool that every C++ developer relies on. It’s a small change — but one that makes everyday C++ just a little bit nicer to work with.

Sometimes, that’s exactly the kind of progress we need.

Connect deeper

If you liked this article, please

hit on the like button,
subscribe to my newsletter
and let’s connect on Twitter!

Hacker Times

Hacker Times

C++26: A User-Friednly assert() macro

Discussion

Discussion

The macro nobody treats like a macro

P2264R7: Making `assert` less fragile

What about diagnostic messages?

But aren’t contracts coming?

Compatibility and availability

Conclusion

Connect deeper

Hacker Times

Hacker Times

C++26: A User-Friednly assert() macro

Discussion

Discussion

The macro nobody treats like a macro

P2264R7: Making assert less fragile

What about diagnostic messages?

But aren’t contracts coming?

Compatibility and availability

Conclusion

Connect deeper

P2264R7: Making `assert` less fragile