Date: Sat, 12 Feb 2022 07:59:56 -0500
+1
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).
I believe there is an Oxford comma missing in the updates to
[format.string.std]p13: "... other than charT and bool, pointer types*,*
or when an integer presentation type is specified" (after "pointer types").
Tom.
On 2/10/2022 6:40 PM, Inbal Levi via SG16 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:
> o LWG3612 <https://cplusplus.github.io/LWG/issue3612> (voted
> into WD in latest plenary P2531R0
> <https://wiki.edg.com/pub/Wg21virtual2022-02/StrawPolls/p2531r0.html>)
> o 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
>
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).
I believe there is an Oxford comma missing in the updates to
[format.string.std]p13: "... other than charT and bool, pointer types*,*
or when an integer presentation type is specified" (after "pointer types").
Tom.
On 2/10/2022 6:40 PM, Inbal Levi via SG16 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:
> o LWG3612 <https://cplusplus.github.io/LWG/issue3612> (voted
> into WD in latest plenary P2531R0
> <https://wiki.edg.com/pub/Wg21virtual2022-02/StrawPolls/p2531r0.html>)
> o 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
>
Received on 2022-02-12 12:59:57