On 4/21/23 1:26 AM, Corentin Jabot wrote:
>
>
> 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
> o Determine interest for participation in a potential new
> UTC project.
> * P2779R0 <https://wg21.link/p2779r0>: Make basic_string_view’s
> range construction conditionally explicit
> o 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.

Ah, great, thank you for that update!

Barry, I'll leave it up to you if you would like to present, but I agree
with Corentin's position that the SG16 concerns are the same for both
proposals.

>
> 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.

I agree; those are the right questions.

Tom.

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