Subject: Re: Wide characters with multiple c-chars
From: Tom Honermann (tom_at_[hidden])
Date: 2020-07-02 12:12:24
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]>>
>>> 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
>>> 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.
>> 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
>> 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.
SG16 list run by email@example.com