C++ Logo

sg16

Advanced search

Re: [SG16] [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: Tom Honermann <tom_at_[hidden]>
Date: Thu, 2 Jul 2020 00:25:40 -0400
On 7/1/20 3:23 AM, 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).
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.
> 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.

Tom.

>
>
> Jens
> _______________________________________________
> Core mailing list
> Core_at_[hidden] <mailto:Core_at_[hidden]>
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core
> Link to this post: http://lists.isocpp.org/core/2020/06/9487.php
>


Received on 2020-07-01 23:28:56