On 9/9/25 3:50 PM, Tom Honermann via SG16 wrote:
>
> SG16 will hold a meeting *tomorrow*, Wednesday, September 10th, at
> 19:30 UTC (timezone conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20250910T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>).
>
> If you need a .ics file to import into your calendar, you can download
> it here
> <https://documents.isocpp.org/remote.php/dav/public-calendars/R7imgS2LJD9xfeWN/94A3D3A0-70B9-4847-935F-9453DB2BB216.ics?export>.
>
> The agenda is:
>
> * P3681R0: char_traits: Stop the bleeding! <https://wg21.link/p3681r0>
> * P3672R0: On Windows, Systems APIs, Text Encodings, and Pragmatism
> <https://wg21.link/p3672r0>.
>
> *P3681R0* is Corentin's attempt to dissuade the continued appearance
> of std::char_traits in new standard library features and comes to us
> following discussions of P3655 (std::zstring_view)
> <https://wg21.link/p3655>. SG16 discussed P3655R0 during the
> 2025-04-23 SG16 meeting
> <https://wiki.edg.com/bin/view/Wg21telecons2025/SG16Teleconference2025-04-23>
> where we took the following poll.
>
> *Poll 1: P3655R0: No objection to use of std::char_traits for
> consistency and compatibility with std::string_view.*
>
> * Attendees: 8 (no abstentions)
> *
> SF
> F
> N
> A
> SA
> 7
> 1
> 0
> 0
> 0
>
> * Strong consensus.
>
> Corentin was not present for that meeting, so this paper does not
> represent a change of opinion from him, but rather a request to
> reconsider that poll and to perhaps establish a policy related to
> std::char_traits for future work. The paper explicitly addresses the
> possibility of custom char trait types and how such existing use with
> std::basic_string would impact convertibility to std::zstring_view.
>
I performed a github code search to try to get a better sense of how
often, and for what purpose, programmers define their own
char_traits-like types. To find such cases, I searched for one of the
more esoteric member function names required to satisfy the character
traits requirements <https://eel.is/c++draft/char.traits.require>;
eq_int_type().

  * blackboxwm defines its own specialization of std::char_traits for
    its bt::Uchar (unsigned int) type
    <https://github.com/bbidulock/blackboxwm/blob/22c0762237d08d04dedd13bcfc4a442a7e5a634d/lib/Unicode.hh#L79-L167>.
  * libxmldiff defines its own specialization of std::char_traits for
    its xmlChar type
    <https://github.com/rpeyron/libxmldiff/blob/673930108f98e74d4b46e5078569efb7a5e2f8d7/src/lx2_str.h#L103-L190>.
  * data-macross-libzmq defines its own specialization of
    std::char_traits for unsigned char
    <https://github.com/jampp/data-macross-libzmq/blob/cca67fdd1b3030ce4daeccc653c71b0671e5ed36/src/blob.hpp#L43-L126>.
  * TheVeryDarkness/MyLibrary defines its own specialization of
    std::char_traits for its UniChar class type
    <https://github.com/TheVeryDarkness/MyLibrary/blob/4477dce87a332014de5f11bd86f1006dff802242/Unicode.h#L65-L117>.
  * cryptagram defines a string16_char_traits type for its
    char16 (unsigned short) type
    <https://github.com/prglab/cryptagram/blob/85e7ddcb3d4c0021495da10c63a0640f8213eed9/experimental/lib/src/string16.h#L56-L123>.
  * ogc defines a traits_nocase type that behaves as a case-insensitive
    variant of std::char_traits<char>
    <https://github.com/norcalli/ogc/blob/3df8fc652c8ce47833d2eba9a5badc1013d2dde0/string-utils.h#L92-L111>.
  * coinflex-exchange/common defines a ci::char_traits template that
    behaves as a case-insensitive variant of std::char_traits<CharT>
    <https://github.com/coinflex-exchange/common/blob/a1967f12b5963a286fc4381f388d67d16845bdf7/ci.h#L22-L40>.
  * tinyexpr-plusplus defines a case_insensitive_char_traits that
    behaves as a case insensitive character traits type for char
    <https://github.com/aiekick/tinyexpr-plusplus/blob/73bdf85e1610a1424e76881bdd4ec941350832a5/tinyexpr.h#L118-L237>.

These are a few of the results
<https://github.com/search?q=eq_int_type&type=code> that showed up on
the first page of the search. The search claimed 20.2k results. I didn't
look further.

Tom.

> *P3672R0* is an opinion paper that discusses encoding expectations on
> different platforms, the consequences of command line arguments and
> file paths that are not well-formed text, the degree to which we
> should care about such content, and the impact such complexity can,
> and should, have on standard library features and interfaces. Thoughts
> on these issues has implications for P3474R0 (std::arguments)
> <https://wg21.link/p3474r0>; a paper we last discussed during the
> 2025-04-09 SG16 meeting
> <https://wiki.edg.com/bin/view/Wg21telecons2025/SG16Teleconference2025-04-09> and
> which is currently awaiting a new revision
> <https://github.com/cplusplus/papers/issues/2128#issuecomment-2791081002>.
>
> Tom.
>
>