Date: Sat, 12 Feb 2022 18:10:29 +0100
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.
> > 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
> >>> >
> >>>
> >>>
> >>>
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.
> > 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
> >>> >
> >>>
> >>>
> >>>
Received on 2022-02-12 17:10:33