> Independent of anything else, I think that P1097 should allow \N{...} in identifiers, for consistency with \u / \U -- I find it very hard to see a reason why the two should be permitted in a different set of contexts. 

+1

There may only be weak reasoning to allow \N identifiers but I think it buys more than disallowing it. 

int \N{LATIN CAPITAL LETTER A WITH MACRON} = 1;

vs:

int \u0100 = 1;

vs:

  int Ā = 1;

At least the \N one gives me a hint what is going on. 

If Ā was part of an external function of a library and I needed to call it, but can't type Ā, the \N form‎ gives a hint. (I would probably hide it behind an inline function either way:

inline Bar AWithMacron‎(Foo foo)

{

    ‎return \N{LATIN CAPITAL LETTER A WITH MACRON}(foo);

}

Sent from my BlackBerry portable Babbage Device

From: Tom Honermann via Core Sent: Thursday, February 27, 2020 12:01 PM To: Richard Smith; C++ Core Language Working Group Reply To: core_at_[hidden] Cc: Tom Honermann; sg16_at_[hidden]; Corentin Jabot Subject: Re: [isocpp-core] [SG16] Renaming universal-character-name

SG16 happened to be meeting and discussing this topic concurrently with Richard's email.  I'll have minutes posted to https://github.com/sg16-unicode/sg16-meetings#february-26th-2020 in the next couple of days.

In that meeting, we had general consensus (we didn't poll) for renaming universal-character-name to unicode-code-point while keeping named-escape-sequence as is with direction that I update P2071 (the successor to P1097) to provide editorial direction for the rename.

I don't have strong opinions on the rename.  I was under the impression that universal-character-name was introduced in C11/C++11, but I see I was mistaken as it is present in C++98.  In retrospect, I don't know why I had that impression.

The fact that this term has been around since C99 and C++98 does give me pause.  I'll refrain from proposing the rename in P2071 pending further discussion.

With regard to allowing \N{...} in identifiers, P2071R0 does mention the possibility of such allowance as a future extension, but without discussion.  I'll update the paper to discuss this.  I recall some discussions about allowing these escapes in identifiers, but I don't think those discussions were in minuted meetings and it hasn't been polled in SG16 or EWG(I).  Personally, I don't see sufficient motivation for allowing one to type:

int \N{LATIN CAPITAL LETTER A WITH MACRON} = 1;

vs:

int \u0100 = 1;

precisely because there is little motivation to be able to type the latter one.  In my mind, use of universal-character-name escapes outside of literals exists as a mechanism to support source character encodings that support characters outside the basic source character set.  Virtually all programmers are going to type the following instead:

int Ā = 1;

Motivation to be able to type the form containing the universal-character-name exists so that identifiers that can't otherwise be represented in the source encoding of a particular source file can still be represented.  I'm not sure that motivation extends to being able to type the named-escape-sequence variant.

Tom.

On 2/26/20 4:25 PM, Richard Smith wrote:

Well, "universal character name" / UCN is established terminology in C and C++ that has been around for more than 20 years, and does not appear to be used for any other purpose. If we rename it, a lot of reference material (for example) will need to be updated. Given that, it's unclear to me that renaming it will be a net improvement, although removing any possible confusion with the "na" property of the character would certainly be a good thing. Also, a UCN is not a codepoint per se -- rather, it is a specific syntax for referring to (naming) a codepoint -- and "character codepoint" seems a bit redundant. If we're going to rename it, something like unicode-escape-sequence would seem more fitting.

Independent of anything else, I think that P1097 should allow \N{...} in identifiers, for consistency with \u / \U -- I find it very hard to see a reason why the two should be permitted in a different set of contexts. And if we do that, then we can just add productions to the existing universal-character-name nonterminal, and not need to rename anything. So I think renaming the grammar production is at least premature. If we do it at all, it should be done by P1097.

On Wed, Feb 26, 2020 at 12:35 PM Tom Honermann via Core <core_at_[hidden]> wrote:

On 2/26/20 5:15 AM, Corentin Jabot via SG16 wrote:

+sg16

On Wed, 26 Feb 2020 at 11:12, Corentin <corentin.jabot_at_[hidden]> wrote:

Hello,

To use terminology more aligned with Unicode and to avoid confusion with character names - which are for example used by P1097R2 - Named character escapes, I would like to rename mechanically universal-character-name to universal-character-codepoint

I was tempted to do this as part of P2029 (Proposed resolution for core issues 411, 1656, and 2333; numeric and universal character escapes in character and string literals), but decided it was too much to bite off as part of that effort.  I do think a rename is in order.

Tom.

Is that something coerce would be willing to do? If so, what would be the best way to do it? Paper targeting core?

Regards,

Corentin

_______________________________________________
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/02/8561.php