SG16 will hold a telecon on Wednesday, April 26th, at 19:30 UTC (timezone conversion).
The agenda follows.
L2/23-107 proposes the creation of a new project within the Unicode Consortium to develop specifications for support of complex scripts in console/terminal command line and text-based user interfaces. Such a specification could eventually provide a standard that could be used by std::format and std::print to produce better results than we know how to do today, even after the significant improvements achieved via P2675 (LWG3780: The Paper (format's width estimation is too approximate and not forward compatible)). We won't spend time reviewing the paper in this telecon, so please read it at your own leisure. Robin has indicated that additional participants for such a project would be appreciated, so we'll take a small amount of time to discuss if anyone would be interested in participating. The UTC is meeting next week, so Robin won't be able to join us, but I'm sure he would be happy to provide additional details for anyone interested.
P2779R0 is a recently
submitted paper that includes SG16 in its audience. It isn't clear
to me that the paper requires SG16 review; I think the concerns
fall more within LEWG's purview. However, a regular SG16 attendee
argued for SG16 to review it. We won't review the paper in this
meeting, but will instead have a brief discussion of whether we
collectively feel SG16 should spend meeting time reviewing this
paper prior to any request from a LEWG chair. Another option would
be to conduct a mailing list review. Briefly, the paper proposes a
heuristic for determining whether a type qualifies as a
string_view-like type for which implicit conversions to std::string_view should be enabled.
Please feel free to share your opinions ahead of time in a reply
to this message.
P2741R1 and P2758R0 are closely related
papers. Both seek to improve the ability of programmers to
influence compile-time diagnostics. Both papers propose
improvements to static_assert to
enable a message to be produced during constant evaluation. The
latter paper proposes additional facilities to issue messages and
errors at compile-time. We'll review both papers, their relative
advantages and, depending on discussion, poll forwarding one or
both papers.
Tom.