On Sat, Jul 22, 2023 at 9:15 PM Tom Honermann via SG16 <
sg16_at_[hidden]> wrote:

> 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>:
> - Determine whether a corresponding proposal for WG21 is desired.
> - P2811R7: Contract-Violation Handlers <https://wg21.link/p2811r7>:
> - 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>:
> - 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.
>
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.


> 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.
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>