On 7/2/20 1:05 PM, Corentin wrote:


On Thu, Jul 2, 2020, 18:59 Tom Honermann <tom@honermann.net> wrote:
On 7/2/20 12:32 PM, Corentin via SG16 wrote:


On Thu, 2 Jul 2020 at 17:50, Tom Honermann <tom@honermann.net> wrote:
On 7/2/20 3:31 AM, Corentin via SG16 wrote:


On Thu, 2 Jul 2020 at 09:09, Corentin <corentin.jabot@gmail.com> 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. 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. 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.