Reclassified as C++23, as there are open LWG issues in this space - LWG3612 and LWG3644.

P2510R1 Formatting pointers (Mark de Wever)

A motion was made on the Library Evolution mailing list on 2022-02-10 to advance this paper directly to electronic polling. The motion failed.

Paper needs more discussion and was scheduled for LEWG telecon on 2022-05-03.

Summery of the mailing list review (started on Feb 10th, 2022):

1. The functionality was supported:

   • I have had the need to format pointers in the various ways described in the paper on numerous occasions (except for locale considerations, but as an opt-in, I see no issue).

2. On the other hand, there was some discussion on the necessity of the proposal:

   • I have a stronger need for seeing: std::println("at {:?p}", p); // '?' is introduced in http://wg21.link/p2286.
     output: at 00007ffb`a67fb331 myLib!myNs::SomeCls, Address is an identity of object in C++, so when printing an address, I want to see what is there.
     Author: The format specializations affected by this paper only format the types (const) void* and nullptr_t. (...) So the pointer has no information regarding the object type it points at, if any.
   • For the '0' and 'P' features, I am not opposed, but also not convinced to the usability of them.

3. Using the locale mechanism got some objection:

   • Allowing locale-dependent printing of pointers in order to get a more readable representation seems a hack to me. If the user goal is a If the user goal is a more readable pointer representation, we should be providing a direct way to obtain it, not something that abuses the localization mechanism to achieve it indirectly.
   • As an option we could remove the more "controversial" locale part. '0' and 'P' seem OK and there were some requests for the former.
   • I am oposed to the paper introducing 'L' as valid specifier for pointers. Using it to get underscore is locale specific, and thus cannot be used in program that want to achieve this formatting in portable way.

4. There was some discussion on the desired formatted output:

   • My preferred output when printing numbers in hexadecimal is 0x05D4; that is, the base prefix is lowercase 0x, but the number itself uses uppercase A-F. This is not a problem for numbers because I can just omit the # and add the base prefix by hand, e.g. 0x{:04X} instead of {:#06X}. But since # is implicit for pointers, this isn't (going to be) possible when using the P specifier.
     Suggestion: # when present will remove the base prefix, instead of adding it.
     Author: Currently # isn't allowed for pointers, so I don't see compatibility or implementation issues. I'll include it in the next version of the paper.
   • Can 'p' work on smart pointers?
     Author: There's a proposal https://wg21.link/p1636r2. But the paper hasn't been updated for a while. I'm not sure whether the author is still pursuing this.
   • What <format> can do to function pointers and pointers to member functions?
     Author: At the moment nothing, but this is an interesting question. I'll give this some more thought and since there's no support yet it's easier to consider adding debug information support from the start.

5. There was a request for implementation.

P2510R2 Formatting pointers (Mark de Wever)

P2510R2: Formatting pointers

P2510R2: Formatting pointers

2022-05-03 Library Evolution Telecon Minutes

Chair: Ben Craig

Minute Taker: Mark Hoemmenn

Champion: Mark de Wever

Summary

Prior to this meeting, this paper was targeting C++23 because it was related to a pair of LWG issues.
This paper is no longer entangled with those issues, and can now target C++26.

POLL: The # specifier should not be valid for pointers

Attendance: 22

# of Authors: 1

Author Position: WA

Outcome: Weak consensus in favor

POLL: Modify P2510R2 (Formatting pointers) by making the '#' specifier not valid for pointers, and then send the revised paper to LWG for C++26 classified as B2 (to be confirmed with a Library Evolution electronic poll).

Attendance: 22

# of Authors: 1

Author Position: SF

Outcome: Strong consensus in favor

Next Steps

The author should revise the paper as directed, and await electronic polling results.

P2510R3 Formatting pointers (Mark de Wever)

2022-07 Library Evolution Electronic Poll Outcomes

Poll 1.10: Send [P2510R3] Formatting Pointers to Library Working Group for C++23, classified as an addition ([P0592R4] bucket 3 item).

Outcome: Poll withdrawn due to incorrect ship vehicle. It will be retaken targeting C++26 in the next electronic polling period.

Scheduled for LWG telecon tomorrow. See the mailing list for details.

2022-10 Library Evolution Electronic Poll Outcomes

Send [P2510R3] Formatting Pointers to Library Working Group for C++26, classified as an addition ([P0592R4] bucket 3 item).

Outcome: consensus in favor.

Update from earlier:

https://wiki.edg.com/bin/view/Wg21telecons2022/P2510-20220907

poll: put P2510R3 in c++26