On 7/2/20 1:05 PM, Corentin wrote:
>
>
> On Thu, Jul 2, 2020, 18:59 Tom Honermann <tom_at_[hidden]
> <mailto:tom_at_[hidden]>> wrote:
>
> On 7/2/20 12:32 PM, Corentin via SG16 wrote:
>>
>>
>> On Thu, 2 Jul 2020 at 17:50, Tom Honermann <tom_at_[hidden]
>> <mailto:tom_at_[hidden]>> wrote:
>>
>> On 7/2/20 3:31 AM, Corentin via SG16 wrote:
>>>
>>>
>>> On Thu, 2 Jul 2020 at 09:09, Corentin
>>> <corentin.jabot_at_[hidden] <mailto:corentin.jabot_at_[hidden]>>
>>> wrote:
>>
>>>
>>> Please note that I am not proposing to make (narrow)
>>> multi character literals ill-formed or deprecated at
>>> this point, there are some uses, and these uses are
>>> intended.
>>>
>>> I would really like your opinion so we can propose that
>>> change to EWG and make the change without taking too
>>> much of anyone's time (the process really isn't tuned
>>> for very small changes, which is why that is part of a
>>> larger paper)
>>>
>> I am weakly against for three reasons:
>>
>> 1. I think there are more valuable efforts for us to spend
>> our time on. I don't find the motivation above
>> compelling. These are legacy features that, as far as I
>> am aware, don't actively cause problems. If evidence can
>> be found to demonstrate that they do actively cause
>> problems, then I might change my mind.
>>
>> I don't think that's ever a compelling reason not to do something
> One of the first questions asked in the incubator groups is
> whether to devote more time to something. In my opinion, this
> doesn't reach the bar for spending more time on it.
>
>
> Do we need to spend time on it?
You seem to be asking us to do so.
> If we don't remove it now, we will deal with it in 40 years.
>
>> 1.
>>
>>
>> 2. Existing compilers are unlikely to change their
>> behavior. Clang, gcc, and icc already issue warnings for
>> use of multicharacter literals (both ordinary and wide)
>> and I suspect they would continue to accept these as
>> extensions (even in their strict compliance modes). The
>> cumulative affect of the proposed change seems to be to
>> require MSVC to issue a warning.
>>
>> Why do you think that?
> As you've mentioned elsewhere, making them ill-formed only
> requires emitting a warning; which most implementations appear to
> already do. I see little motivation for them to do otherwise.
> Users can already elevate that warning to an error via -Werror.
>
>
> You assume compilers care about this extension?
> Do you think msvc should not to have to emit a diagnostic.
> The question is rather simple. Do we believe it is a useful feature?
> If we assume that compiler won't implement any paper there is no point
> standardizing anything.
> What do you think the correct behavior is?

I don't really care about the answers to those questions. This just
isn't something that I personally want to see the committee spend time
on because I don't think it causes problems in practice. If you write a
paper, we will of course consider it. I don't think this will be a slam
dunk and I do think you will encounter resistance in EWG that will
consume time.

Tom.

>> 1.
>>
>>
>> 2. Requiring a diagnostic creates an unnecessary divergence
>> from C.
>>
>> I am sure C would consider aligning.
>
> I'm sure they would consider it, but I'm not at all sure that they
> would choose to do so. WG14 tends to be more conservative than WG21.
>
> Tom.
>
>