Thank you, Robin!

Updates made, details below.

For those that attended, please review and suggest corrections.

 

Corentin mentioned that visual markup for confusability can impact usability and noted that VS Code currently highlights all non-ASCII characters.

I don’t recall what Corentin said exactly, but it should perhaps be noted that what VSCode does is that it highlights non-ASCII characters that are confusable with ASCII (maybe with some exceptions).

This is perhaps even worse than highlighting all non-ASCII: instead of just having everything uniformly highlighted, every other letter is highlighted.

Godbolt uses VSCode, so one can see the effect there: https://gcc.godbolt.org/z/zK7GPo9hW.

Excellent, thank you for that example. Updates made:

• Corentin mentioned that visual markup for confusability can impact usability and noted that VS Code currently highlights all non-ASCII characters that might be confused with an ASCII character.
• [ Editor's note: Following the meeting, Robin Leroy shared an example of current VS Code highlighting as exhibited by Compiler Explorer (Compiler Explorer uses VS Code as its editor). The example code contains Russian text and many of the characters in that text are highlighted as confusable characters despite the surrounding context. The highlighting creates significant distraction that makes the text difficult to read. See https://gcc.godbolt.org/z/zK7GPo9hW. ]

Robin explained that mixed script identifier support is important and provided HTTP_<russion-identifier> as an example in which an identifier is composed of names that originate from different languages.

That would be HTTPЗапрос, a well-attested identifier (for those like me who do not know all of ISO’s official languages, it may be useful to provide a translation: that’s HTTPRequest).

Updated:

• Robin explained that mixed script identifier support is important and provided HTTP_<russion-identifier>HTTPЗапрос as an example in which an identifier is composed of names that originate from different languages.
• [ Editor's note: HTTPЗапрос can be translated as HTTPRequest. ]

Corentin expressed concern that, if C++ were to add support for user-defined operators as Swift did, we don't want to end up in a situation where characters previously allowed in identifiers become candidates for use as operators.

[…]

Robin reported that character reviews are being performed by other members of the Unicode Consortium and that those reviews are considering existing use; for example, those reviews are considering the use of mathematical symbols in Julia and which ones are used for which purposes.

My explanations may have been a bit confusing here.

What I was trying to say was:

1. The rationale for the proposed mathematical notation standard profile for default identifiers takes into account patterns of existing usage, including in Julia and Swift, which allow for user-defined operators, addressing Corentin’s concern.

2. That rationale is being reviewed by relevant experts from other member companies of the Unicode Consortium.

Thank you, that is much more clear. Updated:

• Robin reported that character reviews are being performed by other members of the Unicode Consortium and that those reviews are considering existing use; for example, those reviews are considering the use of mathematical symbols in Julia and which ones are used for which purposes.
• Robin reported that the rationale for the proposed mathematical notation standard profile for default identifiers considers existing use in languages such as Julia and Swift that support user-defined operators.
• Robin stated that relevant experts from other members of the Unicode Consortium are reviewing that rationale.

Le dim. 25 sept. 2022 à 04:48, Tom Honermann via SG16 <sg16@lists.isocpp.org> a écrit :

The summary for the SG16 meeting held September 14th, 2022 is now available.  For those that attended, please review and suggest corrections.

• https://github.com/sg16-unicode/sg16-meetings/#september-14th-2022

No decisions were made at this meeting.

Tom.

--
SG16 mailing list
SG16@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg16