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.