While a lot of unit test libraries, etc. have this "feature" for most/all
their assert macros - it is sort of superfluous and not really a needed
feature if you think about it (you already can print line number, etc. and
should be able to debug most of the time as well).
How much is eg. "current_iterator != container.end()" going to help you
anyway without all the other context ?
There can be an argument for a production type of assert macro in a release
build - but this is not a normal case.

I like the idea if something like should be implemented - but not sure if
its mostly polluting the language with something serving a marginal need
(ie. does not really help a lot anyway) ?

The other (more urgent?) problem with most assert and debug macros in
general is to get evaluation of arguments completely away if not
logging/etc. (which can mean a lot to performance in some situations) -
this is currently only really possible with eg. wrapping in function object
that only gets called if the string to log or whatever is needed (unless
falling back to using macros) - and even that is not completely cost free.
Combined this is the main reason why it is still very hard to switch away
from using macro for many of these cases in general.

Have a lovely day.

Rune




On Wed, Jul 1, 2026 at 8:31 AM Jan Schultke via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> I agree that there should be a more general solution.
>
> Perhaps Expression Templates could have access to the source
> representation of the original expression during expansion, and "procedural
> macros" with Token Injection would obviously be able to access the tokens
> as well.
>
> On Tue, 30 Jun 2026 at 16:53, Sebastian Wittmeier via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> To be honest: I think it is the wrong way. A change in the language for a
>> single use case and not even the use case is fully covered.
>>
>>
>>
>> The preprocessor is good, because it is flexible.
>>
>>
>>
>> Combine your idea with reflection and metaprogramming.
>>
>> Those are the tools for this stuff.
>>
>>
>> -----Ursprüngliche Nachricht-----
>> *Von:* Frederick Virchanza Gotham via Std-Proposals <
>> std-proposals_at_[hidden]>
>> *Gesendet:* Di 30.06.2026 16:41
>> *Betreff:* [std-proposals] Redundify the preprocessor --- Part 1 ----
>> std::labelled
>> *An:* std-proposals <std-proposals_at_[hidden]>;
>> *CC:* Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>;
>> If the verb 'redundify' gets added to the English dictionary in the
>> coming year, you know it was me who started it.
>>
>> I think we can work toward making the preprocessor redundant, but
>> first we need 'std::labelled'.
>>
>> So when you have a function signature as follows:
>>
>> void Func( std::labelled<bool> );
>>
>> Under the hood it gets compiled to:
>>
>> void Func( bool, char const * );
>>
>> And when you invoke it as follows:
>>
>> Func( current_iterator != container.end() );
>>
>> The invocation gets compiled under the hood as:
>>
>> Func( current_iterator != container.end(), "current_iterator !=
>> container.end()" );
>>
>> This would do away with macros such as the following:
>>
>> #define ASSERT_TRUE(condition)
>> \
>> do {
>> \
>> if (!(condition)) {
>> \
>> std::cerr << "Assertion failed at " << __FILE__ << ":"
>> \
>> << __LINE__ << "\n"
>> \
>> << "Expected true, but evaluated to false.\n"
>> \
>> << "Expression: " << #condition << std::endl;
>> \
>> std::abort(); /* Or trigger a breakpoint/test failure */
>> \
>> }
>> \
>> } while (false)
>>
>> because they can be re-written as:
>>
>> inline void AssertTrue(
>> std::labelled<bool> condition,
>> const std::source_location location =
>> std::source_location::current()
>> ) {
>> if (!condition.value()) {
>> std::cerr << "Assertion failed at " <<
>> location.file_name() << ":"
>> << location.line() << "\n"
>> << "Expected true, but evaluated to false.\n"
>> << "Expression: " << condition.c_str() << std::endl;
>> std::abort(); /* Or trigger a breakpoint/test failure */
>> }
>> }
>>
>> What do you reckon?
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>