On Fri, Apr 21, 2023, 04:36 Tom Honermann via SG16 <sg16@lists.isocpp.org> wrote:

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

The agenda follows.

  • L2/23-107: Proper Complex Script Support in Text Terminals
    • Determine interest for participation in a potential new UTC project.
  • P2779R0: Make basic_string_view’s range construction conditionally explicit
    • Determine whether to commit SG16 time to discussing this paper.
  • P2741R1: user-generated static_assert messages
  • P2758R0: Emitting messages at compile time

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.


After Issaquah, we decided that i will work on static assert and Barry will work on consteval diagnostic functions.

But what these papers do is a bit beside the point for SG16, the question is how they do it.

Both papers propose that a message produced during constant evaluation can be grabbed by the compiler and displayed as part of a diagnostic messages ; how should that work?
(See my paper for the answer!).

The answer to this question ought to be the same for all similarly shapped interfaces and once this is resolved EWG can discuss non-encoding related matters

We generally propose support for char and char8_t, the main point of discussions should be:

- how char are interpreted in this scenario
- do we need char8_t
- do we need to support wchar_t, char32_t or what not.