Date: Mon, 26 Sep 2022 14:09:30 +0200
>
> 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.
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
<https://github.com/search?q=HTTP%D0%97%D0%B0%D0%BF%D1%80%D0%BE%D1%81&type=code>
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 HTTP*Request*).
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.
Le dim. 25 sept. 2022 à 04:48, Tom Honermann via SG16 <sg16_at_[hidden]>
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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>
> 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.
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
<https://github.com/search?q=HTTP%D0%97%D0%B0%D0%BF%D1%80%D0%BE%D1%81&type=code>
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 HTTP*Request*).
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.
Le dim. 25 sept. 2022 à 04:48, Tom Honermann via SG16 <sg16_at_[hidden]>
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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>
Received on 2022-09-26 12:09:46