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 <https://wg21.link/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.
<https://github.com/sg16-unicode/sg16-meetings#july-22nd-2020>

Tom.

>
> Thanks
> AlisdairM