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.
>>
>>
>>