C++ Logo


Advanced search

Subject: Re: Updated deprecations paper to reflect SG16 telecon last week
From: Tom Honermann (tom_at_[hidden])
Date: 2020-07-31 23:28:45

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.


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


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


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


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


> I will add poll numbers when the meeting minutes are available.
Minutes are now available at


> Thanks
> AlisdairM

SG16 list run by sg16-owner@lists.isocpp.org