On Wed, Jul 26, 2023 at 1:59 PM Tom Honermann <tom@honermann.net> wrote:
On 7/25/23 9:17 PM, Hubert Tong via SG16 wrote:
On Sat, Jul 22, 2023 at 9:15 PM Tom Honermann via SG16 <sg16@lists.isocpp.org> wrote:

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

The agenda follows.

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.

There can be no conforming extension without a change to the standard. As it stands, parsing for an identifier must end when a dollar sign is encountered because it is considered a separate pp-token. Furthermore, as a member of the basic character set, attempts to use a UCN for it outside of character/string literals is ill-formed.

Ah, yes, thank you for that correction, Hubert!

The extension has been non-conforming since before P25582 (Add @, $, and ` to the basic character set) due to the pp-token issue, correct? So this isn't actually a new concern; just one that is slightly changed due to the new prohibition against use of a UCN to name the $ character outside of literals.

The extension was conforming (i.e., only affected ill-formed code) as late as C++20. $ becomes a UCN in phase 1 and identifier-nondigit took UCNs.
 

Tom.

 

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.

--
SG16 mailing list
SG16@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg16