On 7/27/20 8:28 AM, Alisdair Meredith
via SG16 wrote:
I have started updating P2139 following the telecon last week, and my current
draft can be found at:
https://isocpp.org/files/papers/D2139R3.html
I’d appreciate anyone who attended that can confirm whether I correctly reflect
the position of the group.
Looks good over all. A few comments.
D.20:
- With regard to:
"to avoid premature breakage of clients of the UTF-8/UTF-32
parts of this feature ..."
I think the concern was less about breaking clients and more the
removal of a feature for which the standard does not currently
provide a replacement.
D.21:
- Just a point of clarification in case it isn't well known or
understood. The non-deprecated std::codecvt facets from
<locale> cannot be directly used with std::wstring_convert
and std::wbuffer_convert because they have protected
destructors. A user provided facet with a public destructor is
required (such a class can inherit from a std::codecvt
specialization; cppreference.com provides examples).
D.22:
- With regard to:
"The specific facets in D.22 stand in the way of putting a
minimally
useful replacement into the standard, by sitting on the good
names but with
poor semantics"
I don't think this captures the reuse concern that was discussed
in the meeting. These facets don't prevent providing a
minimally useful replacement; they squat on the specializations
that could potentially be wanted for adding support for
conversions between, for example, UTF-16 and the narrow encoding
as opposed to between UTF-16 and UTF-8. But as discussed in the
meeting, the motivation for pursuing such reuse of these
specializations is very low.
- I think the reason that the zombie clause doesn't apply is
because the zombie clause applies to names and these
deprecations apply to specific specializations of a
non-deprecated name. Presumably, if the deprecated
specializations are removed, an implementation could choose to
re-purpose them.
D.23:
- With regard to:
"SG16 is not persuaded that this is actually a text issue ..."
I think the concern wasn't whether u8path is a text issue, but
rather that, since a suitable replacement exists, whether to
preserve or remove the legacy interface is more of a LEWG
concern than an SG16 one. Per P1253, we do consider
handling of filenames to fall under our purview.
Tom.
I will add poll numbers when the meeting minutes are available.
Minutes are now available at https://github.com/sg16-unicode/sg16-meetings#july-22nd-2020.
Tom.
Thanks
AlisdairM