Reminder that this meeting is taking place tomorrow.

Updated wording is not yet available for P2295, so is dropped from the agenda.  We will therefore focus exclusively on establishing consensus for P2093R6.  As part of that effort, we'll discuss the newly created LWG issue 3565 that Victor requested following our last telecon.  If we run out of time, we'll discuss that issue next time.

I have the following candidate polls prepared.  Thank you to Peter for his assistance in drafting these.  Please respond with suggested refinements so that we can avoid spending telecon time addressing technicalities.

These polls are intended to establish consensus regarding our response to the questions presented below.

Many of the polls are applicable to std::format() as well as std::print().  This is intentional.  The results may be used to guide further papers or resolution of LWG issues.


General polls:

Poll 1: P2093R6: <format> and <print> facilities should have consistent behavior with respect to encoding expectations for the format string.

N.B. Whether encoding expectations exist may depend on other factors, such as what encoding is used for the literal encoding.

Poll 2: P2093R6: <format> and <print> facilities should have consistent behavior with respect to encoding expectations for the output of formatters.

Poll 3: P2093R6: Regardless of format string encoding assumptions, <format> facilities (but not <print> facilities) may be used to format binary data.

N.B. the implementation does not inspect the result of a std::format() invocation, but this is not necessarily true for std::print().


How should invalidly encoded text be handled when transcoding for the purpose of writing directly to a device interface?

Encoding issues may be introduced by any of the following:
Poll 4: P2093R6: <print> facilities exhibit undefined behavior when a format string or formatter output does not match encoding expectations.

N.B. the poll is phrased so as to be independent of whether output is directed to a device or not.

Poll 5: P2093R6: <print> facilities exhibit undefined behavior when a format string or formatter output does not match encoding expectations and output is directed to a device that has encoding expectations.

Poll 6: P2093R6: <print> facility implementors are encouraged to provide a run-time means for diagnosing format strings and formatter output that does not match encoding expectations.

Poll 7: P2093R6: <print> facility implementors are encouraged to substitute U+FFFD replacement characters following Unicode guidance when output is directed to a device and transcoding is necessary.

N.B. transcoding is not necessarily required; e.g., when encoding expectations are for UTF-8 and the device interface expects UTF-8.

Poll 8: P2093R6: Neither <format> nor <print> facilities require an explicit program-controlled error handling mechanism for violations of encoding expectations.

N.B. such error handling mechanisms could be introduced in the future.


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?

Poll 9: P2093R6: Use of UTF-8 as the literal encoding is sufficient for <format> and <print> facilities to assume that the format string and output of all formatters is UTF-8 encoded.


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?

Poll 10: P2093R6: Use of a literal encoding other than UTF-8 is sufficient for <format> and <print> facilities to assume any particular encoding for the format string and output of formatters.


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")?

Poll 11: P2093R6: Support for implicit encoding conversions will only be possible when an encoding assumption is implicitly or explicitly present.

N.B. a future paper could add the ability to pass an explicit encoding tag; std::print(std::text_encoding::id::IBM1047, "{}", u8"hi").


LWG 3565: Handling of encodings in localized formatting of chrono types is underspecified

Poll 12: LWG 3565: Adopt the proposed resolution as is.


Tom.

On 5/31/21 12:45 AM, Tom Honermann via SG16 wrote:

SG16 will hold a telecon on Wednesday, June 9th at 19:30 UTC (timezone conversion).

The agenda is:

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.