4 ms·

I find it unfortunate that so many programming languages (e.g. JavaScript and Python) that purport to support Unicode identifiers actually exclude the most visu

I find it unfortunate that so many programming languages (e.g. JavaScript and Python) that purport to support Unicode identifiers actually exclude the most visually distinctive Unicode characters (i.e. symbols and some emojis) from being used in identifiers, on the entirely specious grounds that they are not Unicode word characters. For example, there are legitimate reasons why one might want to use the mathematical symbols for intersection and union as names of functions, or use circled letters/numbers as/in variable names, but you can't do these things because those are symbols and not Unicode word characters. If you are going to allow Unicode, you should just default to the simplest, most easily memorizable rule (i.e. allow all characters except for ASCII non-word characters). Trying to be helpful by excluding characters you cannot imagine why anyone else might want to use just makes the rule harder to memorize and limits the class of well-former identifiers for no good reason.

marssaxman 3y ago
I once adapted a pre-Unicode compiler (for a weakly-specified dialect of Basic) to accept non-ASCII identifiers in exactly the fashion you suggest. It worked fine, because almost nobody took advantage of the feature, and the myriad avenues for confusion went unexplored. I would not make the same choice today.
- aragonite 3y ago
  Ha! In a way I think that lends support to my suggestion. Allowing all non-ASCII Unicode characters has both positives and negatives. But the negatives are largely negligible, for precisely the reason you mention: most people will not take advantage of that feature (Swift, for example, allows emoji identifiers, but it's extremely rare to find emoji identifiers in actual Swift source code), so the potential for confusion is minimized. On the other hand, the positives (for a small minority of programmers who prefer them) are very real.

marssaxman 3y ago

I once adapted a pre-Unicode compiler (for a weakly-specified dialect of Basic) to accept non-ASCII identifiers in exactly the fashion you suggest. It worked fine, because almost nobody took advantage of the feature, and the myriad avenues for confusion went unexplored. I would not make the same choice today.

aragonite 3y ago
Ha! In a way I think that lends support to my suggestion. Allowing all non-ASCII Unicode characters has both positives and negatives. But the negatives are largely negligible, for precisely the reason you mention: most people will not take advantage of that feature (Swift, for example, allows emoji identifiers, but it's extremely rare to find emoji identifiers in actual Swift source code), so the potential for confusion is minimized. On the other hand, the positives (for a small minority of programmers who prefer them) are very real.