This is your friendly reminder that this meeting is happening today; in
about 6 hours.

Tom.

On 9/11/23 5:44 PM, Tom Honermann via SG16 wrote:
>
> SG16 will hold a telecon on Wednesday, September 13th, at 19:30 UTC
> (timezone conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20230913T193000&p1=1440&p2=tz_pt&p3=tz_mt&p4=tz_ct&p5=tz_et&p6=tz_cest>).
>
> The agenda follows.
>
> * P2845R2: Formatting of std::filesystem::path
> <https://wg21.link/p2845r2>:
> o Continue review.
> * P2728R6: Unicode in the Library, Part 1: UTF Transcoding
> <https://wg21.link/p2728r6>:
> o Continue review.
>
> We last discussed P2845R0 <https://wg21.link/p2845r0> during the
> 2023-07-12 SG16 meeting
> <https://github.com/sg16-unicode/sg16-meetings/tree/master#july-12th-2023>.
> The new revision incorporates feedback previously provided. We'll
> continue review and, if all looks good, poll to forward.
>
> We continued our review of P2728R6 <https://wg21.link/p2728r6> at our
> last meeting on 2023-08-23
> <https://github.com/sg16-unicode/sg16-meetings/tree/master#august-23rd-2023>
> and it remains the current revision. There are still some design
> aspects in the paper that I am not confident that SG16 has consensus
> for. These include:
>
> 1. Our last discussion highlighted the limitations imposed on error
> handling by the iterator interface. Assuming that we agree on a
> simplified error handling approach, I would like to review the
> transcoding_error_handler concept, the utility of the msg
> parameter that is passed to an error handler, and the inability to
> specify an error handler to be used with the utfN_view view
> adapters. The paper provides an explanation in section 5.4.2 for
> why custom error handling is not proposed for the utfN_view
> adapters, but does not provide supporting rationale. Does SG16
> agree with this approach?
> 2. As discussed in section 5.2.3, previous SG16 polls have
> established strong support for relying on code unit type to infer
> encoding. The introduction of the as_charN_t views provides means
> to interpret a sequence of code unit values stored in another type
> as a sequence of charN_t. This suggests the possibility of
> removing the proposed std::uc::format enumeration in favor of
> reliance on charN_t code unit types everywhere. I don't want to
> engage in on-the-fly design discussion; the question is whether
> SG16 would like to pursue such simplification. Are there other
> opportunities for simplification that SG16 would like to pursue?
>
> Finally, I'd like to talk about the bigger picture and how these UTF
> transcoders fit into it. My expectation is that SG16 will eventually
> review proposals that cover encoding and decoding of UTF (and other)
> encodings with extensive error handling capabilities as well as
> features that support transcoding of text in char and wchar_t based
> storage across arbitrary encodings . Do we expect the proposed
> use_replacement_character error handler or other types that model
> transcoding_error_handler to be usable with these other facilities?
> Are the names what we would suggest for their intended scope?
>
> Tom.
>
>