On 01/07/2020 09.23, Corentin Jabot wrote:
>
>
> On Wed, Jul 1, 2020, 00:28 Jens Maurer via Core <core@lists.isocpp.org <mailto:core@lists.isocpp.org>> 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