Mark de Wever wrote:
> Thanks for all feedback.
>
> On Sat, Feb 12, 2022 at 04:04:54PM +0100, Corentin wrote:
> > On Sat, Feb 12, 2022 at 4:02 PM Victor Zverovich
> > <victor.zverovich_at_[hidden]>
> > wrote:
> >
> > > As an option we could remove the more "controversial" locale part.
> > > '0' and 'P' seem OK and there were some requests for the former.
> > >
> >
> > Yes, please!
>
> Based on the feedback regarding the locale, I'll remove it from the next version
> of the paper.

I have a small suggestion to make.

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.

The most straightforward way I see to address that is to simply allow # for
pointers, with the opposite meaning. That is, # when present will remove the
base prefix, instead of adding it.

> > > BTW is there an implementation?
>
> There's no implementation, but I can write one.
>
> Cheers,
> Mark
>
> > >
> > > - Victor
> > >
> > > On Fri, Feb 11, 2022 at 3:29 PM Victor Zverovich <
> > > victor.zverovich_at_[hidden]> wrote:
> > >
> > >> I didn't say that I *like* the locale part. I agree that it's a bit
> > >> hacky but I didn't feel strongly enough to object to the whole
> > >> paper, just called it out.
> > >>
> > >> - Victor
> > >>
> > >> On Fri, Feb 11, 2022 at 2:28 PM Peter Dimov <pdimov_at_[hidden]>
> wrote:
> > >>
> > >>> I now officially can't tell when Victor will like a <format>
> > >>> addition or not.
> > >>>
> > >>> 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 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.
> > >>>
> > >>> > -----Original Message-----
> > >>> > From: Lib-Ext <lib-ext-bounces_at_[hidden]> On Behalf Of
> > >>> > Victor Zverovich via Lib-Ext
> > >>> >
> > >>> > +1
> > >>> >
> > >>> > (Localized formatting of pointers is slightly unorthodox but I
> > >>> > see the
> > >>> value for
> > >>> > readability.)
> > >>> >
> > >>> > Thanks, Mark, for writing this paper.
> > >>> >
> > >>> >
> > >>> > Cheers,
> > >>> > Victor
> > >>> >
> > >>> >
> > >>> > On Thu, Feb 10, 2022 at 3:41 PM Inbal Levi via Lib-Ext <lib-
> > >>> > ext_at_[hidden] <mailto:lib-ext_at_[hidden]> > wrote:
> > >>> >
> > >>> >
> > >>> > Hello LEWG (CCing SG16),
> > >>> > With the design phase of C++23 behind us, we will continue
> > >>> > to
> > >>> process
> > >>> > issues and minor changes targeting C++23. The majority of them
> > >>> > will
> > >>> target
> > >>> > electronic poll directly (as is the following paper)
> > >>> >
> > >>> >
> > >>> > P2510R0 <https://wg21.link/P2510R0> : Formatting pointers
> > >>> >
> > >>> > By: Mark de Wever
> > >>> >
> > >>> > ***
> > >>> >
> > >>> > From the Abstract:
> > >>> > The number of formatting options for pointer types is
> > >>> > limited
> > >>> when
> > >>> > compared to integer types. Since the formatting options are
> > >>> > already implemented for integer types, some of these
> > >>> > restrictions seem
> > >>> unnecessary
> > >>> > and inconsistent. This paper aims to make formatting pointer
> > >>> > types more useful, reducing the need for users to write their
> > >>> > own formatters or
> > >>> casting a
> > >>> > pointer type to an integer type.
> > >>> >
> > >>> >
> > >>> >
> > >>> > Some meta data:
> > >>> >
> > >>> > * The paper mentions two issues:
> > >>> >
> > >>> > * LWG3612 <
> > >>> https://cplusplus.github.io/LWG/issue3612>
> > >>> > (voted into WD in latest plenary P2531R0
> > >>> > <https://wiki.edg.com/pub/Wg21virtual2022-
> 02/StrawPolls/p2531r0.
> > >>> > html>
> > >>> )
> > >>> >
> > >>> > * LWG3644 <
> > >>> https://cplusplus.github.io/LWG/issue3644>
> > >>> > (LWG's priority 2 - important bug)
> > >>> >
> > >>> >
> > >>> > * The paper contains a Tony-table. (Section 2)
> > >>> > * The paper contains wording, as well as updates
> > >>> > `__cpp_lib_format`. (Section 4)
> > >>> > * Please vote with +1 if you support passing the paper to
> > >>> electronic
> > >>> > poll.
> > >>> > (assuming remarks which comes up in the thread
> > >>> > will be addressed / implemented)
> > >>> >
> > >>> > ***
> > >>> >
> > >>> >
> > >>> > Weekly reviews improve the readability of the standard!
> > >>> > By asking questions and sending remarks you indicate to
> > >>> > the
> > >>> authors
> > >>> > which parts of the proposal are not clear, and by doing so,
> > >>> > reduce the
> > >>> chances
> > >>> > of ambiguity in the final draft of the standard.
> > >>> >
> > >>> > Thank you for your time,
> > >>> > Inbal Levi
> > >>> > _______________________________________________
> > >>> > Lib-Ext mailing list
> > >>> > Lib-Ext_at_[hidden] <mailto:Lib-Ext_at_[hidden]>
> > >>> > Subscription:
> > >>> https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
> > >>> > Link to this post:
> > >>> http://lists.isocpp.org/lib-ext/2022/02/22483.php
> > >>> >
> > >>>
> > >>>
> > >>>