On Wed, Jul 26, 2023 at 1:59 PM Tom Honermann <tom_at_[hidden]> 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_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.
>
> Ah, yes, thank you for that correction, Hubert!
>
> The extension has been non-conforming since before P25582 (Add @, $, and
> ` to the basic character set) <https://wg21.link/p2558> 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 <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
>>
>
>