Date: Wed, 10 Apr 2024 12:00:21 -0400
Barry let me know that he got an unexpected conflict for the first 30
minutes of the meeting today. I'll still start the meeting at the
regular time, and will try to find some filler items to discuss until
Barry is able to join in.
Tom.
On 4/9/24 5:46 PM, Tom Honermann via SG16 wrote:
>
> This is your friendly reminder that this meeting is taking place tomorrow.
>
> Tom.
>
> On 4/8/24 4:15 PM, Tom Honermann via SG16 wrote:
>>
>> SG16 will hold a meeting on Wednesday, April 10th, at 19:30 UTC
>> (timezone conversion
>> <https://www.timeanddate.com/worldclock/converter.html?iso=20240410T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>).
>>
>> *For those in Europe, please note that daylight savings time has
>> begun, so this telecon will begin one hour later relative to the last
>> SG16 telecon.*
>>
>> The agenda follows.
>>
>> * P2758R2: Emitting messages at compile time
>> <https://wg21.link/p2758r2>.
>>
>> Though prior revisions of P2758 had an honorable mention in a couple
>> of SG16 meetings last year, this will be our first formal review of
>> it. The initial version of this paper was introduced at the same time
>> as P2741 (user-generated static_assert messages)
>> <https://wg21.link/p2741> with significant overlap in functionality.
>> P2741R3 <https://wg21.link/p2741r3> was adopted for C++26 during the
>> Varna WG21 meeting in 2023 and P2758R2 has been updated to remove the
>> overlap (at least from what is proposed, sections 2.1 and 4 don't
>> appear to have been updated). This paper proposes a set of library
>> functions that enable a custom diagnostic message to be produced as
>> an informative, warning, or error message with corresponding effect
>> on translation success. Please review the prior discussion of P2741R1
>> (user-generated static_assert messages) <https://wg21.link/p2741r1>
>> during the 2024-04-26 SG16 meeting
>> <https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2023.md#april-26th-2023>
>> for context. EWG has already reviewed the proposal during the 2023
>> Issaquah meeting
>> <https://wiki.edg.com/bin/view/Wg21issaquah2023/NotesEWGstaticassert>,
>> during its 2024-01-31 telecon
>> <https://wiki.edg.com/bin/view/Wg21telecons2024/P2758R1-EWG>, and in
>> Tokyo <https://wiki.edg.com/bin/view/Wg21tokyo2024/NotesEWGP2758>;
>> further review is pending LEWG review. As always, we'll discuss
>> encoding related matters but will try to avoid topics that are not
>> otherwise in our purview. Please note that static_assert, as updated
>> by P2741R3, requires that the /static_assert-message
>> <http://eel.is/c++draft/dcl.pre#nt:static_assert-message>/ be encoded
>> in the ordinary literal encoding with use of
>> /universal-character-name
>> <http://eel.is/c++draft/lex.charset#nt:universal-character-name>/ or
>> /simple-escape-sequence
>> <http://eel.is/c++draft/lex.ccon#nt:simple-escape-sequence>/
>> restricted to the /unevaluated-string
>> <http://eel.is/c++draft/lex.string.uneval#nt:unevaluated-string>/ form.
>>
>> We have other papers to review, but I am freshly back from vacation
>> and other authors are either unavailable or I haven't made contact
>> with them yet (and won't do so with such little notice). So, this
>> might be a short meeting.
>>
>> Tom.
>>
>>
>
minutes of the meeting today. I'll still start the meeting at the
regular time, and will try to find some filler items to discuss until
Barry is able to join in.
Tom.
On 4/9/24 5:46 PM, Tom Honermann via SG16 wrote:
>
> This is your friendly reminder that this meeting is taking place tomorrow.
>
> Tom.
>
> On 4/8/24 4:15 PM, Tom Honermann via SG16 wrote:
>>
>> SG16 will hold a meeting on Wednesday, April 10th, at 19:30 UTC
>> (timezone conversion
>> <https://www.timeanddate.com/worldclock/converter.html?iso=20240410T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>).
>>
>> *For those in Europe, please note that daylight savings time has
>> begun, so this telecon will begin one hour later relative to the last
>> SG16 telecon.*
>>
>> The agenda follows.
>>
>> * P2758R2: Emitting messages at compile time
>> <https://wg21.link/p2758r2>.
>>
>> Though prior revisions of P2758 had an honorable mention in a couple
>> of SG16 meetings last year, this will be our first formal review of
>> it. The initial version of this paper was introduced at the same time
>> as P2741 (user-generated static_assert messages)
>> <https://wg21.link/p2741> with significant overlap in functionality.
>> P2741R3 <https://wg21.link/p2741r3> was adopted for C++26 during the
>> Varna WG21 meeting in 2023 and P2758R2 has been updated to remove the
>> overlap (at least from what is proposed, sections 2.1 and 4 don't
>> appear to have been updated). This paper proposes a set of library
>> functions that enable a custom diagnostic message to be produced as
>> an informative, warning, or error message with corresponding effect
>> on translation success. Please review the prior discussion of P2741R1
>> (user-generated static_assert messages) <https://wg21.link/p2741r1>
>> during the 2024-04-26 SG16 meeting
>> <https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2023.md#april-26th-2023>
>> for context. EWG has already reviewed the proposal during the 2023
>> Issaquah meeting
>> <https://wiki.edg.com/bin/view/Wg21issaquah2023/NotesEWGstaticassert>,
>> during its 2024-01-31 telecon
>> <https://wiki.edg.com/bin/view/Wg21telecons2024/P2758R1-EWG>, and in
>> Tokyo <https://wiki.edg.com/bin/view/Wg21tokyo2024/NotesEWGP2758>;
>> further review is pending LEWG review. As always, we'll discuss
>> encoding related matters but will try to avoid topics that are not
>> otherwise in our purview. Please note that static_assert, as updated
>> by P2741R3, requires that the /static_assert-message
>> <http://eel.is/c++draft/dcl.pre#nt:static_assert-message>/ be encoded
>> in the ordinary literal encoding with use of
>> /universal-character-name
>> <http://eel.is/c++draft/lex.charset#nt:universal-character-name>/ or
>> /simple-escape-sequence
>> <http://eel.is/c++draft/lex.ccon#nt:simple-escape-sequence>/
>> restricted to the /unevaluated-string
>> <http://eel.is/c++draft/lex.string.uneval#nt:unevaluated-string>/ form.
>>
>> We have other papers to review, but I am freshly back from vacation
>> and other authors are either unavailable or I haven't made contact
>> with them yet (and won't do so with such little notice). So, this
>> might be a short meeting.
>>
>> Tom.
>>
>>
>
Received on 2024-04-10 16:00:26