C++ Logo

SG16

Advanced search

Subject: Re: Emojis in identifiers
From: Marcos Bento (marcosbento_at_[hidden])
Date: 2020-06-23 10:24:12


On Tue, Jun 23, 2020 at 4:27 PM Corentin Jabot <corentinjabot_at_[hidden]>
wrote:

>
> Emojis are not just codepoints, they are a complex grammar that cannot
> just be "allowed", there needs to be a non trivial support. In fact the
> only sane way to support that would be to only allow the "recommended for
> general interchange" emojis from a specific list.
> See http://unicode.org/reports/tr51/ for details.
>

I understand that there are technical issues that make emoji "undesirable"
-- namely, as you point out, the unnecessary(?) complexity that identifying
emojis would introduce in tools.
My suggestion would be to add that explanation of (or a reference to) the
rationale behind the decision.

But again it should be driven by an analysis of use cases for emojis in
> identifiers and the impact on future evolution (emojis are symbols). For
> example Swift found itself in a situation where some emojis are considered
> identifiers and other custom operators.
>
> Same for other scripts, individual letters are allowed but ZWNJ are not.
> UAX#31 lists these scenarios. A quick survey seems to show that there is
> no demand for Farsi, for example, because neither tools or people like to
> deal with mixed-directions languages. Is that a chicken egg problem ? Maybe
>
> Other partially supported scripts are those which use a virama
> https://en.wikipedia.org/wiki/Virama , which is not
> semantically meaningful.
>
> My understanding is that it is not customary for Brahmic scripts to be
> used in programming languages, because of poor IDE or input support, or
> cultural reasons.
> I would definitely love to see a proposal for this, but it should
> ultimately be driven by people familiar with these scripts and who
> understand the demand for them.
>

My point is that it would be interesting to have clear indication in the
paper of what we are effectively dropping.

Maybe we can see it as a matter of educating the reader. Just in case
someone is currently coding C++ in Brahmic, for example, is warned.

And again, we need to adopt the proposal as presented to find ourselves in
> a clean slate from which we can build upon iteratively as/if demand arises.
>
>



SG16 list run by sg16-owner@lists.isocpp.org