Date: Tue, 30 Jul 2024 18:38:35 -0400
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.
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-30 22:38:40