On Thu, Jul 2, 2020, 08:01 Tom Honermann <tom_at_[hidden]> wrote:

> On 7/2/20 1:40 AM, Corentin Jabot wrote:
>
>
>
> 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]>
>> 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 ;)
>
Yes, we just disagree on what makes the specification clearer, that's fine!

> (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)).
>

Agreed, although I think the standard should make that ill-formed, forcing
a diagnostic

> Tom.
>
>
>
> Tom.
>>
>>
>>
>>> Jens
>>> _______________________________________________
>>> Core mailing list
>>> 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
>>>
>>
>>
>