Since this paper has character encoding considerations, I'm going to schedule it for SG16 review.

Relevant to https://isocpp.org/files/papers/P2758R0.html#improving-static_assert, see the previously discussed paper (which I authored) https://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4433.html and the corresponding EWG notes on the wiki from the Lenexa meeting.

Of note, it already contains potential wording, but was never reviewed by a Core expert and likely needs updating since we've done lots of character encoding work since then.

This was discussed in EWG during the February 8, 2023 afternoon session in Issaquah. The following polls were taken:

EWG would like to encourage more work on P2741R0 (static_assert-with-constexpr-message), solicit feedback from SG16, and see it again with core expert reviewed wording.

Result: Consensus

EWG would like to encourage more work on P2758 in the direction of constexpr_print_str/constexpr_error_str.

Result: Consensus

EWG ALSO would like to encourage more work on this topic that can print multiple errors per constant evaluation, but still result in a failed TU.

Result: Consensus

EWG would like to encourage more work on P2758 in the direction of a constexpr std::format.

Result: Consensus

@tahonermann we can remove the SG16 tag from thar, right? SG16 guidance was given in #1434

@cor3ntin, the guidance provided in #1434 is clearly applicable, but I would prefer to see an updated paper that removes the duplication with P2741 and that has wording that implements that guidance first so that SG16 can definitively approve forwarding a specific revision.

@tahonermann you are right, but i think we lost a needs-revision on this paper then.
@jfbastien you might want to ask barry whether he actually wants to present in Varna.

I checked with @brevzin, he says:

once SG16 is happy with arbitrary object, the rest of my paper just follows suit I think. Just need to drop the part that Corentin is covering.

So let's mark it as needing revision and track @cor3ntin 's paper first. Once @cor3ntin 's paper proceeds (or dies!) we can move this one accordingly.

I checked with @brevzin, he says:

once SG16 is happy with arbitrary object, the rest of my paper just follows suit I think. Just need to drop the part that Corentin is covering.

So let's mark it as needing revision and track @cor3ntin 's paper first. Once @cor3ntin 's paper proceeds we can move this one accordingly.

Ahem. FTFY.

I'm going to retain the SG16 label for now. EWG can, and should, proceed with any review desired of course, but I want to run a new revision by SG16 since we haven't discussed the parts of the paper that are not covered by P2741 (user-generated static_assert messages).

P2758R1 Emitting messages at compile time (Barry Revzin, )

P2758R2 Emitting messages at compile time (Barry Revzin)

P2758R4 Emitting messages at compile time (Barry Revzin)

2025-01-28 Library Evolution Telecon

P2758R4: Emitting messages at compile time

2025-01-28 Library Evolution Telecon Minutes

Champion: Barry Revzin
Chair: Inbal Levi
Minute Taker: Andreas Weis

Summary

POLL: We would like to rename the std::constexpr_print_str overloads to std::constexpr_debug_print_str.

Attendance: 31
Author's Position: N
Outcome: No consensus for a change

POLL: We would like to remove all the std::constexpr_print_str overloads from the proposal.

Attendance: 29
Author's Position: SA
Outcome: Consensus against

F: Implementation concerns in the current form

POLL: We would like to remove the std::constexpr_print_str(string_view) overload from the proposal (as we want to control marking it with tags)

Attendance: 29
Author's Position: SA
Outcome: Consensus against

POLL: We would like to explore alternative design for the interface currently proposed in P2758 (e.g. taking an enum with severity, or otherwise).

Attendance: 29
Author's Position: SA
Outcome: Strong consensus against

POLL: Make the interface described in P2758R4 “consteval” (by that eliminating them from working on run-time)

Attendance: 29
Author's Position: SA
Outcome: Consensus against

POLL: Forward P2758R4 to LWG (pending SG16’s approval)

Attendance: 28
Author's Position: SF
Outcome: Strong consensus in favor

Paper forwarding checklist:

• Why should this facility go into the standard library? Usable at compile time
• Examples? Yes
• Field experience?
  • Implementation experience? Some
  • Usage experience? Some, within “reflection” and the standard lib
  • Deployment experience? No
• Performance considerations? N/A
• Constexpr? YES 🙂
• Discussion of prior art? Yes
• Changes Library Evolution previously requested? N/A (discussed on reflector prior to the meeting)
• Support for "std::format", "hash", and allocators (if required)? N/A
• Wording? Yes
• Feature test macro? No (targets same vehicle as “Reflection”, if missed can be reconsidered)

Next Steps

Paper was forwarded to LWG, pending SG16 review of:

1. Wording for restrictions on tag string and message string,
2. Adding overloads accept a u8string_view.

@tahonermann please remove the SG16 lable after seen, so that LWG will know they can look at it. Thank you! :)

CWG 2025-02-13 in Hagenberg: Assigned for pre-review.

Note: When are such messages emitted for constexpr/consteval destructors?

SG16 reviewed P2758R4 during the 2025-02-05 SG16 meeting. The following polls were taken.

• Poll 3: P2758R4: Add overloads that allow the message to be passed as std::u8string_view.
  • Attendees: 9 (two abstentions)

    SF	F	N	A	SA
    4	2	1	0	0

  • Consensus.
• Poll 4: P2758R4: Add overloads that allow the message to be passed as std::wstring_view.
  • Attendees: 9 (two abstention)

    SF	F	N	A	SA
    0	2	2	2	1

  • No consensus.
  • A/SA: std::wstring_view is mostly useful on Windows at run-time, we don't really need it
    at compile-time.
• Poll 5: P2758R4: Add overloads that allow the message to be passed as std::u16string_view and std::u32string_view.
  • Attendees: 9 (two abstention)

    SF	F	N	A	SA
    0	1	5	1	0

  • No consensus.
• Poll 6: P2758R4: Forward to LEWG modified to include std::u8string_view overloads.
  • Attendees: 9 (two abstention)

    SF	F	N	A	SA
    3	4	0	0	0

  • Strong consensus.

SG16 asked for changes, so I'm adding the needs-revision label. The requested change to add support for std::u8string_view is important for reflection; without it, the standard library doesn't provide a way to print the message returned from std::meta::exception::what() at compile-time; see P3560R0 which is on track for C++26 per #2206.

I'll retain the SG16 label for now to confirm that SG16's request has been addressed once a new revision is submitted.

@inbal2l, @brevzin, see above.

Thank you to SG16 for the valuable input!
Was forwarded to LWG (pending the approval of SG16). Assuming P2758R5 apply the requested changes (will be verified by SG16 chair and myself), no need for us to see this again. Also notified explicitly in the beginning of 2025-03-18 telecon.

P2758R5 Emitting messages at compile time (Barry Revzin)