Clearing LEWG and LEWGI tags for now as we want the C Interop Study Group (SG22) to look at this first. @AaronBallman, once SG22 has forwarded this, please remove any needs-revision tag and add a LEWG tag.

SG22 reviewed this paper at our Mar 05, 2021 meeting.

Should the assert macro be changed to be a variadic macro along the lines of P2264R0?
SF F N A SA (WG21)
2 7 2 2 0 (Author voted: SF) Consensus

SF F N A SA (WG14)
3 1 0 0 0 (Consensus)

WG14 also reviewed this paper at the March 2021 plenary.

Does WG14 wish to see something along the lines of N2621 in C23:
Favor/Oppose/Abstain
7/3/8 (No consensus for change)

@AaronBallman and @cor3ntin please chat and determine if LEWG needs to see this.

@brycelelbach WG14 didn't like the paper so unfortunately WG21 has to see it

@brycelelbach WG14 didn't like the paper so unfortunately WG21 has to see it

Agreed. SG22 voted with consensus, so I think LEWG should see this. However, LEWG should be aware that WG14 does not have consensus for the change (so adoption of the proposal as-is would mean WG21 is introducing an incompatibility with C). If LEWG sees the paper and suggests substantial direction changes, it may be worth putting it back on the SG22 plate.

The author has indicated this needs revision.

P2264R1 Make assert() macro user friendly for C and C++ (Peter Sommerlad)

P2264R2 Make assert() macro user friendly for C and C++ (Peter Sommerlad)

Deferred to C++26.

2022-11-09 13:00 to 15:00 UTC-10 Kona Library Evolution Meeting

2022-11-09 13:00 to 15:00 UTC-10 Kona Library Evolution Minutes

Champion: n/a (Fabio Fracassi presenting)

Chair: Fabio Fracassi

POLL: Forward P2264 to LWG as B2 Priority item for C++26 (to be confirmed by electronic polling) as an approved design.

Attendance: 20 + 5

# of Authors: 0

Author Position: n/a

Outcome: Unanimous consent

Summary

We think of this as a letter of intend to keep/restore compatibility with C's assert Macro as soon as possible

Next Steps

Take a Library Evolution electronic poll to send P2264R4 (Make assert() macro user friendly for C and C++) to Library for C++26, classified as B2 - improvement.

2022-11 Library Evolution Electronic Poll Outcomes

Poll 2.6: Send [P2264R4] Make assert Macro User Friendly For C And C++ to Library Working Group for C++26, classified as an improvement of an existing feature ([P0592R4] bucket 2 item).

Outcome: Consensus in favor.

https://wiki.edg.com/bin/view/Wg21issaquah2023/P2264R2-20230209

LWG reviewed at Issaquah. There are impenetrability concerns that need to be addressed.

This might be a naïve question, but everyone seems to agree that we must keep assert as a macro. Why, tho? All of that could much easier be done if it were a language primitive. Of course, if <cassert> is not included, assert is a free identifier and a lot of people make use of it. But isn’t that solved by introducing __assert (or _Assert) as a keyword and have <cassert> simply #define assert __assert? A language-defined __assert can be completely parallel to static_assert.

This is addressed by P2884. (Github paper issue is currently missing. Why?)

Added now: #1561.

This is addressed by P2884. (Github paper issue is currently missing. Why?)

That paper is new for the May mailing that just completed. I'm guessing that (all of) the github issues for that mailing just haven't been created yet. Odd though, I see one for P2901.

LWG reviewed at Issaquah. There are impenetrability concerns that need to be addressed.

Implementability concerns too ;-)

This might be a naïve question, but everyone seems to agree that we must keep assert as a macro. Why, tho? All of that could much easier be done if it were a language primitive. Of course, if <cassert> is not included, assert is a free identifier and a lot of people make use of it. But isn’t that solved by introducing __assert (or _Assert) as a keyword and have <cassert> simply #define assert __assert? A language-defined __assert can be completely parallel to static_assert.

This is addressed by P2884 : #1561.

Just to confirm that P2884 addresses only the comment about keywords, and not the issues addressed by P2264 itself.

P2264R5 Make assert() macro user friendly for C and C++ (Peter Sommerlad)

Sent to LEWG for "contextual conversion to bool" concerns (see R5 revision history entry in the paper).

The author decided to avoid the explicit conversion to bool, so we will not see this in LEWG.
Sending back to LWG.
@JeffGarland @jwakely - please verify that the paper rebates correctly on C++ version

P2264R6 Make assert() macro user friendly for C and C++ (Peter Sommerlad, )

P2264R7 Make assert() macro user friendly for C and C++ (Peter Sommerlad, )