Date: Tue, 1 Sep 2020 12:59:51 -0400
On Tue, Sep 1, 2020 at 11:01 AM Steve Downey <sdowney_at_[hidden]> wrote:
>
> I'm not sure about C, but for C++ the grammar for static_assert is
> static_assert-declaration:
> static_assert ( constant-expression ) ;
> static_assert ( constant-expression , string-literal ) ;
> So the value for the string is going to be encoded in the target
> environment, rather than the source. While all characters from the
> basic source character set and the execution character set are going
> to be available, the values for those characters may not actually be
> suitable for emitting. No idea what compilers do today. String-literal
> also allows for encoding prefix, so the associated encoding might be
> Unicode. Or even a wide string.
> Do we need to have an 'original spelling' rule for static_assert?
C has the same grammar for static assertions, and [[deprecated]],
[[nodiscard]], and static_assert all use a string-literal (with no
mention of encoding prefixes). Personally, I would like to see
encoding prefixes be ill-formed in these cases, but I was going for
incremental improvement on the question of what to do with strings
(without a prefix) with characters outside the basic character set. Do
we have an "original spelling" rule somewhere else already in C++?
~Aaron
>
> On Tue, Sep 1, 2020 at 10:13 AM Aaron Ballman via SG16
> <sg16_at_[hidden]> wrote:
> >
> > I've been working on a paper (attached) for WG14 that I also intend to
> > submit to WG21 (with C++-specific wording) and am looking for some
> > early feedback from SG16 as the topic relates to text encoding of
> > diagnostic messages.
> >
> > The basic thrust of the paper is that both languages have constructs
> > which can produce diagnostics including user-defined text and don't
> > have a "compiler diagnostic character set" defined to convert the text
> > into. So the paper tries to limit the damage by allowing characters
> > outside of the basic source character set to be handled as a matter of
> > QoI. The paper also asks a question that Tom H posed to me, which is
> > whether we want the restriction to be against the basic execution
> > character set for slightly easier handling of \r and \n.
> >
> > Any feedback you feel like providing is appreciated. Thanks!
> >
> > ~Aaron
> > --
> > SG16 mailing list
> > SG16_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>
> I'm not sure about C, but for C++ the grammar for static_assert is
> static_assert-declaration:
> static_assert ( constant-expression ) ;
> static_assert ( constant-expression , string-literal ) ;
> So the value for the string is going to be encoded in the target
> environment, rather than the source. While all characters from the
> basic source character set and the execution character set are going
> to be available, the values for those characters may not actually be
> suitable for emitting. No idea what compilers do today. String-literal
> also allows for encoding prefix, so the associated encoding might be
> Unicode. Or even a wide string.
> Do we need to have an 'original spelling' rule for static_assert?
C has the same grammar for static assertions, and [[deprecated]],
[[nodiscard]], and static_assert all use a string-literal (with no
mention of encoding prefixes). Personally, I would like to see
encoding prefixes be ill-formed in these cases, but I was going for
incremental improvement on the question of what to do with strings
(without a prefix) with characters outside the basic character set. Do
we have an "original spelling" rule somewhere else already in C++?
~Aaron
>
> On Tue, Sep 1, 2020 at 10:13 AM Aaron Ballman via SG16
> <sg16_at_[hidden]> wrote:
> >
> > I've been working on a paper (attached) for WG14 that I also intend to
> > submit to WG21 (with C++-specific wording) and am looking for some
> > early feedback from SG16 as the topic relates to text encoding of
> > diagnostic messages.
> >
> > The basic thrust of the paper is that both languages have constructs
> > which can produce diagnostics including user-defined text and don't
> > have a "compiler diagnostic character set" defined to convert the text
> > into. So the paper tries to limit the damage by allowing characters
> > outside of the basic source character set to be handled as a matter of
> > QoI. The paper also asks a question that Tom H posed to me, which is
> > whether we want the restriction to be against the basic execution
> > character set for slightly easier handling of \r and \n.
> >
> > Any feedback you feel like providing is appreciated. Thanks!
> >
> > ~Aaron
> > --
> > SG16 mailing list
> > SG16_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg16
Received on 2020-09-01 12:03:35