Date: Sat, 2 Apr 2022 00:17:15 +0300
Hello,
Thank you all, for your useful input, I'm sure the author appreciates it.
Few design considerations came up in the thread, so the paper will need to
be discussed in a telecon before moving forward.
*Paper was scheduled for LEWG telecon on 2022-05-03 (15:00 UTC).*
*Attaching a summary of the main issues which came up in the thread:*
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.
Best regards,
Inbal Levi
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Tuesday, February 15th, 2022 at 12:49 PM, Tomasz Kamiński via Lib-Ext <
lib-ext_at_[hidden]> wrote:
For the '0' and 'P' features, I am not opposed, but also not convinced to
the usability of them.
I think introducing any "feature"
that we already have
(reinterpret_cast<uiniptr_t> + x)
by occupying severely precious
mini-language grammar in the
standard is a waste of design
space. GCC and Clang have
been issuing warnings on %08p
for a long time. Which means,
if we want to flip the impression
of "%p has no flags," the
outcome must be useful enough
to teach. And I believe more
useful things can be done on
0 + p or P, more useful than
saving some keystrokes.
Thank you all, for your useful input, I'm sure the author appreciates it.
Few design considerations came up in the thread, so the paper will need to
be discussed in a telecon before moving forward.
*Paper was scheduled for LEWG telecon on 2022-05-03 (15:00 UTC).*
*Attaching a summary of the main issues which came up in the thread:*
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.
Best regards,
Inbal Levi
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Tuesday, February 15th, 2022 at 12:49 PM, Tomasz Kamiński via Lib-Ext <
lib-ext_at_[hidden]> wrote:
For the '0' and 'P' features, I am not opposed, but also not convinced to
the usability of them.
I think introducing any "feature"
that we already have
(reinterpret_cast<uiniptr_t> + x)
by occupying severely precious
mini-language grammar in the
standard is a waste of design
space. GCC and Clang have
been issuing warnings on %08p
for a long time. Which means,
if we want to flip the impression
of "%p has no flags," the
outcome must be useful enough
to teach. And I believe more
useful things can be done on
0 + p or P, more useful than
saving some keystrokes.
-- Zhihao Yuan, ID lichray The best way to predict the future is to invent it. On Tue, 15 Feb 2022 at 22:49, Tomasz Kamiński <tomaszkam_at_[hidden]> wrote: > 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. If digits > separators is desired, the should be explored as separate modifier, that is > also applicable to integers. > For the '0' and 'P' features, I am not opposed, but also not convinced to > the usability of them. > > W dniu 12.02.2022 o 16:04, Corentin via Lib-Ext pisze: > > > > 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! > > >> >> BTW is there an implementation? >> >> - 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 >>>> > >>>> >>>> >>>> > _______________________________________________ > Lib-Ext mailing listLib-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/22500.php > > >
Received on 2022-04-01 21:17:28