On Fri, Apr 21, 2023, 04:36 Tom Honermann via SG16 <sg16_at_[hidden]>
wrote:

> SG16 will hold a telecon on Wednesday, April 26th, at 19:30 UTC (timezone
> conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20230426T193000&p1=1440&p2=tz_pt&p3=tz_mt&p4=tz_ct&p5=tz_et&p6=tz_cest>
> ).
>
> The agenda follows.
>
> - L2/23-107 <https://www.unicode.org/L2/L2023/23107-terminal-suppt.pdf>:
> Proper Complex Script Support in Text Terminals
> - Determine interest for participation in a potential new UTC
> project.
> - P2779R0 <https://wg21.link/p2779r0>: Make basic_string_view’s
> range construction conditionally explicit
> - Determine whether to commit SG16 time to discussing this paper.
> - P2741R1 <https://wg21.link/p2741r1>: user-generated static_assert
> messages
> - P2758R0 <https://wg21.link/p2758r0>: Emitting messages at compile
> time
>
> L2/23-107 <https://www.unicode.org/L2/L2023/23107-terminal-suppt.pdf>
> 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))
> <https://wg21.link/p2675>. 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 <https://wg21.link/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 <https://wg21.link/p2741r1> and P2758R0
> <https://wg21.link/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.


Tom.
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>