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