Subject: Re: [isocpp-core] New draft revision: D2029R2 (Proposed resolution for core issues 411, 1656, and 2333; numeric and universal character escapes in character and string literals)
From: Corentin Jabot (corentinjabot_at_[hidden])
Date: 2020-07-01 02:53:51
On Wed, 1 Jul 2020 at 09:34, Jens Maurer <Jens.Maurer_at_[hidden]> wrote:
> On 01/07/2020 09.23, Corentin Jabot wrote:
> > On Wed, Jul 1, 2020, 00:28 Jens Maurer via Core <core_at_[hidden]
> <mailto:core_at_[hidden]>> wrote:
> > On 30/06/2020 06.15, Corentin Jabot via SG16 wrote:
> > > No, especially wide multi characters that are simply not a thing,
> let's not make them one.
> > I don't follow. In the status quo working draft, we have in
> [lex.ccon] p5
> > after the note:
> > "The value of a wide-character literal containing multiple c-char s
> is implementation-defined."
> > I would rather it doesn't have a name, especially not one that makes it
> look like it behaves like multi character literals, which it doesn't (not
> an int, value computed differently). As such I would like it if core would
> consider keeping the above sentence below the table ( same thing for what
> tom calls conditional characters literals - both of them).
> > Giving names to things tends to make them feel more important or
> intended, which I think we should avoid in this case.
> From a CWG perspective, clarity of specification rules. If giving
> names to things helps, then there shall be names.
> "Feel of importance" is not relevant from that perspective.
But does giving a name helps or does it exactly the opposite?
"The value of a wide-character literal containing multiple c-char s is
implementation-defined." was perfectly understandable
Same for the description of characters that cannot be encoded.
Like, if we go further in that direction should there be "partially
non-encodable strings literals", etc?
And if not, why should we describe '<NON ENCODABLE c-char>' differently
from "<NON ENCODABLE s-char>" ?
To be clear I _really_ like the tables proposed by Tom, I just wish we
wouldn't try to put everything in in it
> That said, I agree that "conditional character literal" is an odd name,
> and I've made a suggestion for a different one in my other e-mail.
SG16 list run by email@example.com