Date: Wed, 23 Oct 2024 15:24:08 -0400
Reminder that we will be meeting in about 10 minutes.
Corentin won't be able to attend this meeting, so we won't discuss P2019
today.
Victor, if you are prepared to do so, we could discuss LWG4156
(error_category messages have unspecified encoding)
<https://cplusplus.github.io/LWG/issue4156> if other attendees feel
adequately prepared to discuss it.
Tom.
On 10/22/24 2:24 PM, Tom Honermann via SG16 wrote:
>
> SG16 will hold a meeting *tomorrow*, Wednesday, October 23rd, at 19:30
> UTC (timezone conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20241023T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>).
>
> The agenda follows.
>
> * P3374R0: Adding formatter for fpos<mbstate_t>
> <https://wg21.link/p3374r0>
> * P2019R7: Thread attributes <https://wg21.link/p2019r7>
>
> P3374R0 comes to us courtesy of Liang Jiaming and seeks to add
> formatting support for std::fpos<std::mbstate_t>. SG16 has not
> previously reviewed this proposal, but previous discussion occurred on
> the std-proposals mailing list in the thread starting here
> <https://lists.isocpp.org/std-proposals/2024/07/10667.php> and on the
> SG16 mailing list in a thread starting here
> <https://lists.isocpp.org/sg16/2024/08/4415.php>. Please try to review
> those before the meeting (and I again apologize for such late notice).
> std::mbstate_t is an implementation-defined type, so we can't
> legislate much about its representation in formatted output, but we
> can provide guidance, particularly with regard to whether formatted
> values of the type should be sufficient to reconstruct values in a
> hypothetical scanner such as that proposed by P1729 (Text Parsing)
> <https://wg21.link/p1729>.
>
> P2019R7 was reviewed by SG16 during the 2024-09-25 meeting in which
> the following polls were taken:
>
> * Poll 2: P2019R7: Name hint should be provided in the ordinary
> literal encoding.
> o Attendees: 8
> o
> SF
> F
> N
> A
> SA
> 3
> 1
> 3
> 1
> 0
>
> o Weak consensus.
> * Poll 3: P2019R7: Name hint should be provided as an NTMBS in the C
> locale encoding.
> o Attendees: 8
> o
> SF
> F
> N
> A
> SA
> 1
> 5
> 1
> 0
> 1
>
> o Consensus
>
> The guidance provided regarding encoding of the name hint is fairly
> clear despite some continued opposition, so new information should be
> provided in order to reopen that discussion. Continued discussion is
> warranted for other concerns raised regarding POSIX vs Windows
> platforms and the use of std::string_view. We'll focus first on those
> topics and then any other concerns that are raised.
>
> Tom.
>
>
Corentin won't be able to attend this meeting, so we won't discuss P2019
today.
Victor, if you are prepared to do so, we could discuss LWG4156
(error_category messages have unspecified encoding)
<https://cplusplus.github.io/LWG/issue4156> if other attendees feel
adequately prepared to discuss it.
Tom.
On 10/22/24 2:24 PM, Tom Honermann via SG16 wrote:
>
> SG16 will hold a meeting *tomorrow*, Wednesday, October 23rd, at 19:30
> UTC (timezone conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20241023T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>).
>
> The agenda follows.
>
> * P3374R0: Adding formatter for fpos<mbstate_t>
> <https://wg21.link/p3374r0>
> * P2019R7: Thread attributes <https://wg21.link/p2019r7>
>
> P3374R0 comes to us courtesy of Liang Jiaming and seeks to add
> formatting support for std::fpos<std::mbstate_t>. SG16 has not
> previously reviewed this proposal, but previous discussion occurred on
> the std-proposals mailing list in the thread starting here
> <https://lists.isocpp.org/std-proposals/2024/07/10667.php> and on the
> SG16 mailing list in a thread starting here
> <https://lists.isocpp.org/sg16/2024/08/4415.php>. Please try to review
> those before the meeting (and I again apologize for such late notice).
> std::mbstate_t is an implementation-defined type, so we can't
> legislate much about its representation in formatted output, but we
> can provide guidance, particularly with regard to whether formatted
> values of the type should be sufficient to reconstruct values in a
> hypothetical scanner such as that proposed by P1729 (Text Parsing)
> <https://wg21.link/p1729>.
>
> P2019R7 was reviewed by SG16 during the 2024-09-25 meeting in which
> the following polls were taken:
>
> * Poll 2: P2019R7: Name hint should be provided in the ordinary
> literal encoding.
> o Attendees: 8
> o
> SF
> F
> N
> A
> SA
> 3
> 1
> 3
> 1
> 0
>
> o Weak consensus.
> * Poll 3: P2019R7: Name hint should be provided as an NTMBS in the C
> locale encoding.
> o Attendees: 8
> o
> SF
> F
> N
> A
> SA
> 1
> 5
> 1
> 0
> 1
>
> o Consensus
>
> The guidance provided regarding encoding of the name hint is fairly
> clear despite some continued opposition, so new information should be
> provided in order to reopen that discussion. Continued discussion is
> warranted for other concerns raised regarding POSIX vs Windows
> platforms and the use of std::string_view. We'll focus first on those
> topics and then any other concerns that are raised.
>
> Tom.
>
>
Received on 2024-10-23 19:24:10