+1

I think the paper addresses this implicitly but it could maybe be called
out more explicitly: the impact on user code is (presumably?) negligible
due to the unhelpfulness of these facets.

Fraser

On Fri, 31 Jan 2025 at 10:42, Alisdair Meredith via SG16 <
sg16_at_[hidden]> wrote:

> Never mind — I am still digesting my first morning caffeine.
>
> The wording IS in the table, no issue to file, my +1 remains but I should
> reconfirm once the caffeine has taken hold and my reasoning is more
> reliable!
>
> AlisdairM
>
> On Jan 31, 2025, at 10:39 AM, Alisdair Meredith <alisdairm_at_[hidden]> wrote:
>
> I believe I took my list from [locale.category]p2, table
> 86: [tab:locale.category.facets]
>
> That lists only the two instantiations I mentioned. It sounds like we
> should add `codecvt<wchar_t, char, mbstate_t>` to that list?
>
> I observe that this change hits only an observation in the rationale, and
> not any of the essential reasoning, nor has any impact on the proposed
> wording (other than opening an LWG issue for the above).
>
> Unsurprisingly, my vote for my own paper is +1, and I will file an LWG
> issue to address the missing entry in the locale category facets table.
>
> AlisdairM
>
> On Jan 30, 2025, at 2:31 PM, Tom Honermann <tom_at_[hidden]> wrote:
>
> 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.
>
>
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>