Date: Wed, 31 Jul 2024 15:26:12 -0400
This meeting will start in 5 minutes!
Tom.
On 7/30/24 6:38 PM, Tom Honermann via SG16 wrote:
>
> SG16 will hold a meeting *tomorrow* on Wednesday, July 31st, at 19:30
> UTC (timezone conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20240731T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>).
>
> The agenda follows.
>
> * P3068R2: Allowing exception throwing in constant-evaluation
> <https://wg21.link/p3068r2>.
> * LWG issue 4087: Standard exception messages have unspecified
> encoding <https://cplusplus.github.io/LWG/issue4087>.
>
> LEWG has requested that we review P3068R2 with respect to
> std::exception and related types and encoding concerns for the message
> provided by the what() member function. The concerns are effectively
> the same as those reported in LWG 4087, but in the special case of
> constant evaluation.
>
> We discussed LWG 4087 during the 2024-06-12 SG16 meeting
> <https://github.com/sg16-unicode/sg16-meetings#june-12th-2024>.
> Unfortunately, I still haven't published the meeting summary for that
> meeting (work, life, burnout), so that link isn't helpful right now.
> I'll respond to this email with a copy of the (excellent) minutes that
> Eddie Nolan took for that meeting. We spent much of that meeting
> discovering what the status quo is with regard to the standard
> wording. We didn't poll any direction. The status quo appears to be:
>
> * what() returns an implementation-defined NTBS per [exception]p5
> <http://eel.is/c++draft/exception#5>.
> * what() permits return of an NTMBS per [exception]p6
> <http://eel.is/c++draft/exception#6>.
> * The NTMBS encoding is dependent on the C++ locale; it is the
> encoding that the std::codecvt<wchar_t, char, std::mbstate_t>
> facet uses on the char side of the conversion per the reference in
> [exception]p6 <http://eel.is/c++draft/exception#6>.
> * There is no guarantee that the C++ locale has not changed in
> between construction of an exception object and a call to what()
> for that same object.
> * The postconditions of the std::exception copy constructor and
> assignment operator and the constructors of the exception classes
> declared in <stdexcept> all require that what() return a pointer
> to an exact copy of the what_arg string provided when the
> exception object was constructed; no transcoding is permitted. The
> postconditions of std::filesystem::filesystem_error are similar
> per [fs.filesystem.error.members]
> <http://eel.is/c++draft/fs.filesystem.error.members>.
> * We might be able to strengthen the requirements for handling of
> encodings for std::filesystem::filesystem_error::what()
> specifically; normative encouragement is present per
> [fs.filesystem.error.members]p7
> <http://eel.is/c++draft/fs.filesystem.error.members#7>.
>
> The status quo suggests that, for the purposes of std::format(), the
> string returned by what() should be treated as containing (possibly
> ill-formed) text in the NTMBS encoding of the current C++ locale (or
> perhaps an explicitly provided std::locale argument).
>
> With respect to P3068R2, there is currently no notion of a locale
> dependent NTMBS encoding during constant evaluation. We'll need to
> discuss the ramifications of this, presumably identify an encoding to
> use instead (presumably the ordinary literal encoding), and determine
> how to adjust wording accordingly.
>
> Tom.
>
>
Tom.
On 7/30/24 6:38 PM, Tom Honermann via SG16 wrote:
>
> SG16 will hold a meeting *tomorrow* on Wednesday, July 31st, at 19:30
> UTC (timezone conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20240731T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>).
>
> The agenda follows.
>
> * P3068R2: Allowing exception throwing in constant-evaluation
> <https://wg21.link/p3068r2>.
> * LWG issue 4087: Standard exception messages have unspecified
> encoding <https://cplusplus.github.io/LWG/issue4087>.
>
> LEWG has requested that we review P3068R2 with respect to
> std::exception and related types and encoding concerns for the message
> provided by the what() member function. The concerns are effectively
> the same as those reported in LWG 4087, but in the special case of
> constant evaluation.
>
> We discussed LWG 4087 during the 2024-06-12 SG16 meeting
> <https://github.com/sg16-unicode/sg16-meetings#june-12th-2024>.
> Unfortunately, I still haven't published the meeting summary for that
> meeting (work, life, burnout), so that link isn't helpful right now.
> I'll respond to this email with a copy of the (excellent) minutes that
> Eddie Nolan took for that meeting. We spent much of that meeting
> discovering what the status quo is with regard to the standard
> wording. We didn't poll any direction. The status quo appears to be:
>
> * what() returns an implementation-defined NTBS per [exception]p5
> <http://eel.is/c++draft/exception#5>.
> * what() permits return of an NTMBS per [exception]p6
> <http://eel.is/c++draft/exception#6>.
> * The NTMBS encoding is dependent on the C++ locale; it is the
> encoding that the std::codecvt<wchar_t, char, std::mbstate_t>
> facet uses on the char side of the conversion per the reference in
> [exception]p6 <http://eel.is/c++draft/exception#6>.
> * There is no guarantee that the C++ locale has not changed in
> between construction of an exception object and a call to what()
> for that same object.
> * The postconditions of the std::exception copy constructor and
> assignment operator and the constructors of the exception classes
> declared in <stdexcept> all require that what() return a pointer
> to an exact copy of the what_arg string provided when the
> exception object was constructed; no transcoding is permitted. The
> postconditions of std::filesystem::filesystem_error are similar
> per [fs.filesystem.error.members]
> <http://eel.is/c++draft/fs.filesystem.error.members>.
> * We might be able to strengthen the requirements for handling of
> encodings for std::filesystem::filesystem_error::what()
> specifically; normative encouragement is present per
> [fs.filesystem.error.members]p7
> <http://eel.is/c++draft/fs.filesystem.error.members#7>.
>
> The status quo suggests that, for the purposes of std::format(), the
> string returned by what() should be treated as containing (possibly
> ill-formed) text in the NTMBS encoding of the current C++ locale (or
> perhaps an explicitly provided std::locale argument).
>
> With respect to P3068R2, there is currently no notion of a locale
> dependent NTMBS encoding during constant evaluation. We'll need to
> discuss the ramifications of this, presumably identify an encoding to
> use instead (presumably the ordinary literal encoding), and determine
> how to adjust wording accordingly.
>
> Tom.
>
>
Received on 2024-07-31 19:26:18