C++ Logo

sg16

Advanced search

Re: Backward compatibility impact from P2071 (Named universal character escapes)

From: Jakub Jelinek <jakub_at_[hidden]>
Date: Thu, 8 Sep 2022 14:07:01 +0200
On Wed, Aug 31, 2022 at 04:51:23PM -0400, Tom Honermann wrote:
> It seems I failed to provide an actual example of the backward compatibility
> impact in the initial message.
>
> Prior to P2071 (and P2290 (Delimited escape sequences) <wg21.link/p2290>),
> the following was well-formed. It is now ill-formed because a is not
> expanded (because the escape sequence now combines with a to form a longer
> identifier), lookup for the (longer) identifier fails, and the following )
> is extraneous.
>
> #define z(x) 0
> #define a z(
> int x = a\N{LATIN SMALL LETTER E WITH ACUTE});
> int y = a\u{00E9});
>
> This example is pretty contrived, but perhaps an annex C entry should be
> added.

On the GCC side, we went with never emitting warnings or errors just
for \N not followed by { when outside of string/character literals,
not treating \N{ or \u{ as any extension outside of string/character
literals in strict standard modes (-std=c{89,99,11,17,++{98,11,14,17,20}};
obviously except for -std=c++{23,2b}) and when treating it as an extension
just warning instead of errors outside of string/character literals if it
isn't valid P2071/P2290 form and in that case it is treated as separate
tokens like before.
So, to use \u{00E9} or \N{LATIN SMALL LETTER E WITH ACUTE} in identifiers
with the C++23 meaning one needs to use -std=c++{23,2b} or the GNU
extension modes (-std=gnu{89,99,11,17,++{98,11,14,17,20,23,2b}}).

        Jakub

Received on 2022-09-08 12:07:09