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