Date: Thu, 30 Jan 2025 14:31:37 -0500
Alisdair, I did notice one error while reviewing the paper. The last
sentence of section 4 (Problem Description) states:
The Standard itself neither instantiates nor uses
std::codecvt<wchar_t, char, mbstate_t>!
That isn't correct. That specialization is used by at least
std::basic_file_buf ([filebuf.general]p7
<https://eel.is/c++draft/input.output#filebuf.general-7>) and
std::filesystem::path constructors ([fs.path.construct]p6
<https://eel.is/c++draft/input.output#fs.path.construct-6>). I'm not
sure if the above statement was perhaps intended to reference a
different specialization.
Tom.
On 1/30/25 2:23 PM, Tom Honermann via SG16 wrote:
>
> This is the second SG16 mailing list review that I previously
> communicated we would conduct this week.
>
> *Poll: Forward P2873R2 <https://wg21.link/p2873r2> (Remove Deprecated
> Locale-Category Facets for Unicode from C++26) to LEWG*
>
> Please respond with +1 if you are in favor of the poll and -1 if you
> believe this paper needs further review in an SG16 meeting in which
> case, please also summarize your concerns.
>
> Please reply before our February 5th meeting.
>
> Note that a +1 response does not indicate that you approve of the
> paper; it only indicates that you believe the paper adequately
> addresses and/or represents SG16 related concerns, either in the
> proposed design itself or in prose that adequately describes such
> concerns and the options for addressing them. The goal is to ensure
> the paper presents sufficient information for LEWG to make a well
> informed decision.
>
> SG16 previously reviewed P2873R0 <https://wg21.link/p2873r0> during
> its 2023-05-24
> <https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2023.md#may-24th-2023>
> and 2023-10-25
> <https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2023.md#october-25th-2023>
> (briefly and tangentially, search for "P2873") meetings. These reviews
> followed previous discussion of the same topic/proposal in the context
> of P2139R2 (Reviewing Deprecated Facilities of C++20 for C++23)
> <https://wg21.link/p2139r2> section D.22 (Deprecated locale category
> facets [depr.locale.category]) during the 2020-07-22 SG16 meeting
> <https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2020.md#july-22nd-2020>.
> There was no consensus for removal during the 2020-07-22 review, but
> there was consensus for no objection against removal (should LEWG
> decide to do so despite no SG16 recommendation to remove). No concerns
> were raised in the more recent reviews, but we never polled actually
> forwarding the paper. What appears to have happened is that Inbal sent
> it back to us following the first review with a request that the paper
> be expanded to better explain why these features were deprecated to
> begin with. The later revisions have not altered what is proposed
> (beyond adding an annex C entry), but have significantly expanded the
> history, the design concerns with these facets, the motivation for
> deprecation, and the current implementation status with regard to the
> deprecation.
>
> Tom.
>
>
sentence of section 4 (Problem Description) states:
The Standard itself neither instantiates nor uses
std::codecvt<wchar_t, char, mbstate_t>!
That isn't correct. That specialization is used by at least
std::basic_file_buf ([filebuf.general]p7
<https://eel.is/c++draft/input.output#filebuf.general-7>) and
std::filesystem::path constructors ([fs.path.construct]p6
<https://eel.is/c++draft/input.output#fs.path.construct-6>). I'm not
sure if the above statement was perhaps intended to reference a
different specialization.
Tom.
On 1/30/25 2:23 PM, Tom Honermann via SG16 wrote:
>
> This is the second SG16 mailing list review that I previously
> communicated we would conduct this week.
>
> *Poll: Forward P2873R2 <https://wg21.link/p2873r2> (Remove Deprecated
> Locale-Category Facets for Unicode from C++26) to LEWG*
>
> Please respond with +1 if you are in favor of the poll and -1 if you
> believe this paper needs further review in an SG16 meeting in which
> case, please also summarize your concerns.
>
> Please reply before our February 5th meeting.
>
> Note that a +1 response does not indicate that you approve of the
> paper; it only indicates that you believe the paper adequately
> addresses and/or represents SG16 related concerns, either in the
> proposed design itself or in prose that adequately describes such
> concerns and the options for addressing them. The goal is to ensure
> the paper presents sufficient information for LEWG to make a well
> informed decision.
>
> SG16 previously reviewed P2873R0 <https://wg21.link/p2873r0> during
> its 2023-05-24
> <https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2023.md#may-24th-2023>
> and 2023-10-25
> <https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2023.md#october-25th-2023>
> (briefly and tangentially, search for "P2873") meetings. These reviews
> followed previous discussion of the same topic/proposal in the context
> of P2139R2 (Reviewing Deprecated Facilities of C++20 for C++23)
> <https://wg21.link/p2139r2> section D.22 (Deprecated locale category
> facets [depr.locale.category]) during the 2020-07-22 SG16 meeting
> <https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2020.md#july-22nd-2020>.
> There was no consensus for removal during the 2020-07-22 review, but
> there was consensus for no objection against removal (should LEWG
> decide to do so despite no SG16 recommendation to remove). No concerns
> were raised in the more recent reviews, but we never polled actually
> forwarding the paper. What appears to have happened is that Inbal sent
> it back to us following the first review with a request that the paper
> be expanded to better explain why these features were deprecated to
> begin with. The later revisions have not altered what is proposed
> (beyond adding an annex C entry), but have significantly expanded the
> history, the design concerns with these facets, the motivation for
> deprecation, and the current implementation status with regard to the
> deprecation.
>
> Tom.
>
>
Received on 2025-01-30 19:31:39