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-02 00:40:47
On Thu, Jul 2, 2020, 06:25 Tom Honermann <tom_at_[hidden]> wrote:
> On 7/1/20 3:23 AM, Corentin Jabot wrote:
> On Wed, Jul 1, 2020, 00:28 Jens Maurer via Core <core_at_[hidden]>
>> 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
> 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).
> Corentin, I don't understand this statement about multicharacter literals
> having different behavior. Yes, ordinary and wide multicharacter literals
> have different types. So do ordinary and wide character literals. For
> both kinds of multicharacter literals, the value is implementation-defined;
> I don't know where this claim that they are computed differently comes from.
Look at how they are implemented in practice, and look at usages ( or lack
thereof in the case of wide characters with multiple c-char).
Implementers just pick one one of the c-char and encode that.
> 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.
> I disagree. Names are given to make things easier to refer to and
> discuss. These different behaviors are clearly intended. Giving something
> a name is not synonymous with endorsing it.
I am afraid the only way I will win this this is to convince ewg to make
that ill-formed, isn't it?
>> Core mailing list
>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core
>> Link to this post: http://lists.isocpp.org/core/2020/06/9487.php
SG16 list run by email@example.com