Following the meeting I tweaked the wording
https://isocpp.org/files/papers/D2741R2.pdf (and removed support for
char8_t)
I found talking about the second or third form unwieldy, so i added a
"static-assert-message" grammar element which its own requirements.

Thanks,

Corentin.

On Wed, Apr 26, 2023 at 9:31 PM Tom Honermann via SG16 <
sg16_at_[hidden]> wrote:

> This meeting is happening now.
>
> Tom.
> On 4/25/23 3:02 PM, Tom Honermann via SG16 wrote:
>
> This is your friendly reminder that this meeting is taking place tomorrow.
>
> I don't expect Barry to be joining us tomorrow, so we likely won't be
> discussing P2758R0.
>
> Tom.
> On 4/20/23 10:36 PM, Tom Honermann via SG16 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.
>
> Tom.
>
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>