On Tue, Jun 23, 2020 at 4:27 PM Corentin Jabot <firstname.lastname@example.org> 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 ? MaybeOther 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.