https://www.sandordargo.com/blog/2026/03/25/cpp26-user-friendly-assert avatar Sandor Dargo's Blog On C++, software development and books * HOME * TAGS * ARCHIVES * BOOKS * SPEAKING * DAILY C++ * HI... * [become_a_p] Blog 2026 03 25 C++26: A User-Friendly assert() macro Post [ ] Cancel C++26: A User-Friendly assert() macro Sandor Dargo Mar 25 2026-03-25T00:00:00+01:00 Mar 25 2026-03-25T16:49:39+01:00 4 min 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: 1 // https://godbolt.org/z/9sqM7PvWh 2 using Int = int; 3 int x = 1, y = 2; 4 5 assert(std::is_same::value); 6 assert([x, y]() { return x < y; }() == 1); 7 assert(std::vector{1, 2, 3}.size() == 3); 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{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: 1 assert(x > 0 , "x was not greater than zero"); 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: 1 assert(x > 0 && "x was not greater than zero"); 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! [yH5BAEAAAA] dev cpp cpp26 reflection syntax This post is licensed under CC BY 4.0 by the author. [yH5BAEAAAA] [yH5BAEAAAA] Share Recent Update * C++26: A User-Friendly assert() macro * C++26: Span improvements * Time in C++: C++20 Brought Us Time Zones * Lesson of a booking: Don't trust the system! * Why should we always catch exceptions by reference? Trending Tags cpp books watercooler career tutorial cpp23 stl algorithms self-improvement management Contents Further Reading Dec 11, 2024 2024-12-11T00:00:00+01:00 Let's start exploring C++26 During the last 2 years, we spent a lot of time exploring C++23 resulting in almost 40 blog posts. I'm not saying that we covered every single new language or library feature, but we covered most o... Dec 18, 2024 2024-12-18T00:00:00+01:00 C++26: Delete with a reason Let's start exploring C++26 with a simple but useful change. Thanks to Yihe Li's proposal (2573R2), when we =delete a special member function or a function overload, we can specify a reason. This ... Jan 1, 2025 2025-01-01T00:00:00+01:00 C++26: user-generated static_assert messages Our first quest into the world of C++26 was about =delete with an optional error message, which improves the readability of the source code and potentially the error messages. In this next part of ... C++26: Span improvements - Comments powered by Disqus. (c) 2026 Sandor Dargo. Some rights reserved. Powered by Jekyll with Chirpy theme. Trending Tags cpp books watercooler career tutorial cpp23 stl algorithms self improvement management