SG16 will hold a telecon on Wednesday, July 26th, at 19:30 UTC (timezone
conversion
<https://www.timeanddate.com/worldclock/converter.html?iso=20230726T193000&p1=1440&p2=tz_pt&p3=tz_mt&p4=tz_ct&p5=tz_et&p6=tz_cest>).

The agenda follows.

  * WG14 N3145: $ in Identifiers v2
    <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3145.pdf>:
      o Determine whether a corresponding proposal for WG21 is desired.
  * P2811R7: Contract-Violation Handlers <https://wg21.link/p2811r7>:
      o Discuss character encoding considerations for the
        std::contracts::contract_violation::comment() member function.
  * LWG 3944: Formatters converting sequences of char to sequences of
    wchar_t <https://wg21.link/lwg3944>:
      o Continue review pending a proposed resolution or related paper.

Hubert suggested in a post to the SG16 mailing list
<https://lists.isocpp.org/sg16/2023/07/3891.php> that SG16 consider
whether similar changes to those adopted for C2x via WG14 N3145
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3145.pdf> to allow $
in identifiers as a sanctioned implementation-defined allowance are
desirable. All major C++ implementations currently allow $ in
identifiers by default with no warning, even with -Wall;
https://godbolt.org/z/M154z7bGf. Some implementations issue a warning in
their pedantic modes. All implementations provide an option to prohibit
$ in identifiers. We'll discuss the impact (or lack thereof) to
implementations regarding an implementation-defined allowance vs a
conforming extension.

SG21 has been making good progress on a contracts feature for C++26 and
recently approved P2811R7 <https://wg21.link/p2811r7>. When a contract
violation occurs, a violation handler is invoked and passed a
std::contracts::contract_violation object whose comment() member
function is expected to reflect portions of the source code. Per
proposal 1.3 ("The comment property") in section 4.1 ("An Extensible
contract_violation Type"), the intent is that the function return text
encoded in the literal encoding. The proposed wording simply states that
the function returns implementation-defined text. We'll discuss whether
to recommend any changes.

LWG 3944 <https://wg21.link/lwg3944> was discussed during the 2023-07-12
SG16 meeting
<https://github.com/sg16-unicode/sg16-meetings/#june-7th-2023> (that
link will work soon) and is pending a proposed resolution or paper. If
an update is provided and time permits, we'll continue discussion.

Tom.