This is your friendly reminder that this meeting is taking place tomorrow.

Thank you to Corentin for his recent reminder of P2342 (For a Few Punctuators More). If possible, please read the section on $ as it provides excellent historical context that is relevant for the discussion of WG14 N3145.

Also thank you to Mark for providing a proposed resolution for LWG 3944. Please try to review that for tomorrow as well.

Tom.

On 7/22/23 9:15 PM, Tom Honermann via SG16 wrote:

SG16 will hold a telecon on Wednesday, July 26th, at 19:30 UTC (timezone conversion).

The agenda follows.

WG14 N3145: $ in Identifiers v2:

Determine whether a corresponding proposal for WG21 is desired.

P2811R7: Contract-Violation Handlers:

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:

Continue review pending a proposed resolution or related paper.

Hubert suggested in a post to the SG16 mailing list that SG16 consider whether similar changes to those adopted for C2x via WG14 N3145 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. 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 was discussed during the 2023-07-12 SG16 meeting (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.