Date: Mon, 31 May 2021 00:45:30 -0400
SG16 will hold a telecon on Wednesday, June 9th at 19:30 UTC (timezone
conversion
<https://www.timeanddate.com/worldclock/converter.html?iso=20210609T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>).
The agenda is:
* D2295R4: Support for UTF-8 as a portable source file encoding
<https://isocpp.org/files/papers/D2295R4.pdf>
o Review updated wording produced through collaboration between
Corentin, Jens, and Hubert to resolve earlier feedback at
https://lists.isocpp.org/sg16/2021/04/2353.php.
* P2093R6: Formatted output <https://wg21.link/p2093r6>
o Continue discussion and poll for consensus on answers to the
following questions:
1. How should invalidly encoded text be handled when
transcoding for the purpose of writing directly to a device
interface?
2. Is use of UTF-8 as the literal encoding a sufficient
indicator that all input fed to std::format() and
std::print() (including the format string, programmer
supplied field arguments, and locale provided text) will be
UTF-8 encoded?
3. Is the literal encoding a sufficient indicator in general
that all input fed to std::format() and std::print()
(including the format string, programmer supplied field
arguments, and locale provided text) will be provided in an
encoding compatible with the literal encoding?
4. What are the implications for future support of
std::print("{} {} {} {}", L"Wide text", u8"UTF-8 text",
u"UTF-16 text", U"UTF-32 text")?
Discussion of D2295R4 is contingent on updated wording being available.
For P2093R6, I believe we have sufficiently discussed transcoding
concerns (including concerns related to locale provided field arguments)
to be able to answer the first question above with strong consensus. I
likewise suspect that further discussion on the third question is
unnecessary and that we are reasonably well positioned to poll it. We
began discussion around the second question at the last telecon, but I
feel that some more discussion is needed. We haven't discussed question
four at all, but I expect to arrive at a clearly objective answer for
that one.
I would like for us to complete discussion and polling for P2093 during
this telecon. I don't know if that is realistic, but that is what we'll
aim for. I will reply to this email with a set of candidate polls in
advance of the telecon with the hope that we'll be able to reduce time
negotiating polls during the telecon itself.
Tom.
conversion
<https://www.timeanddate.com/worldclock/converter.html?iso=20210609T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>).
The agenda is:
* D2295R4: Support for UTF-8 as a portable source file encoding
<https://isocpp.org/files/papers/D2295R4.pdf>
o Review updated wording produced through collaboration between
Corentin, Jens, and Hubert to resolve earlier feedback at
https://lists.isocpp.org/sg16/2021/04/2353.php.
* P2093R6: Formatted output <https://wg21.link/p2093r6>
o Continue discussion and poll for consensus on answers to the
following questions:
1. How should invalidly encoded text be handled when
transcoding for the purpose of writing directly to a device
interface?
2. Is use of UTF-8 as the literal encoding a sufficient
indicator that all input fed to std::format() and
std::print() (including the format string, programmer
supplied field arguments, and locale provided text) will be
UTF-8 encoded?
3. Is the literal encoding a sufficient indicator in general
that all input fed to std::format() and std::print()
(including the format string, programmer supplied field
arguments, and locale provided text) will be provided in an
encoding compatible with the literal encoding?
4. What are the implications for future support of
std::print("{} {} {} {}", L"Wide text", u8"UTF-8 text",
u"UTF-16 text", U"UTF-32 text")?
Discussion of D2295R4 is contingent on updated wording being available.
For P2093R6, I believe we have sufficiently discussed transcoding
concerns (including concerns related to locale provided field arguments)
to be able to answer the first question above with strong consensus. I
likewise suspect that further discussion on the third question is
unnecessary and that we are reasonably well positioned to poll it. We
began discussion around the second question at the last telecon, but I
feel that some more discussion is needed. We haven't discussed question
four at all, but I expect to arrive at a clearly objective answer for
that one.
I would like for us to complete discussion and polling for P2093 during
this telecon. I don't know if that is realistic, but that is what we'll
aim for. I will reply to this email with a set of candidate polls in
advance of the telecon with the hope that we'll be able to reduce time
negotiating polls during the telecon itself.
Tom.
Received on 2021-05-30 23:45:35