On 7/2/20 1:40 AM, Corentin Jabot wrote:
>
>
> On Thu, Jul 2, 2020, 06:25 Tom Honermann <tom_at_[hidden]
> <mailto: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] <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.
>
>
> 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.
That is exactly the reason these are specified to be
conditionally-supported with implementation-defined values.
>
>> 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?

The goal isn't to win; it is to have a clear specification. But should
a proposal to make them ill-formed be adopted, I would shed no tears ;)

(I think it would not be unreasonable to propose removing these from the
standard because, arguably, the standard should not specify anything
that is conditionally-supported with implementation-defined behavior
(unless the implementation-defined behavior is selected from a set of
options specified by the standard; which isn't the case here)).

Tom.

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