Are there any plans to support Unicode as a variable name?

[qcks]

Are there any plans to support Unicode as a variable name?

[devoncarew]

cc @lrhn

[lrhn]

No current plans, no.

It's not an unreasonable idea, but it has also not been a big priority. It will affect parsing time (currently non-ASCII characters can only occur inside comments and string literals in a valid Dart program, which makes tokenization simpler. It doesn't have to recognize whether a sequence of bytes is a Unicode identifierStart/identifierPart or not, something which requires a potentially large table to figure out).

[mateusfccp]

I'm looking forward to name my variables with emojis.

[lrhn]

I'm fairly sure pictographic characters are not considered identifier characters, so I wouldn't expect var 🎄 = 🌲 + ⭐ ; to become reality. Too bad, var 🦄 🌈 = false;.

[munificent]

I specifically think we should not support arbitrary Unicode letters in identifiers. There are too many homoglyphs which can make code confusingly wrong at best or mask deliberate security bugs at worst.

[boukeversteegh]

I specifically think we should not support arbitrary Unicode letters in identifiers. There are too many homoglyphs which can make code confusingly wrong at best or mask deliberate security bugs at worst.

Sounds like a problem area indeed, but on the other hand, it would only be the concern to those developers choosing to use non-ascii identifiers. Have you ever run into this issue @qcks in another programming language, and if so, how do you tend to avoid this?

[qcks]

I specifically think we should not support arbitrary Unicode letters in identifiers. There are too many homoglyphs which can make code confusingly wrong at best or mask deliberate security bugs at worst.

Sounds like a problem area indeed, but on the other hand, it would only be the concern to those developers choosing to use non-ascii identifiers. Have you ever run into this issue @qcks in another programming language, and if so, how do you tend to avoid this?

Simply put, the variable names are long and smelly.

[miaosun009]

I want to have that characteristic

[munificent]

it would only be the concern to those developers choosing to use non-ascii identifiers.

The way developers work today with massive open source ecosystems, package managers, and deep dependency graphs, we are all using lots of lots of code that we don't have much control over.

[feinstein]

I think this can lead to pranks, where people could sneak in some invisible characters into someone else's work and make them spend a good while trying to figure out why the analyzer is complaining. +1 for security concerns.

[munificent]

I'm going to go ahead and close this because the language team has no plans to do this. If at some point in the future we do decide to consider it, we can always reopen the bug, but I think that's relatively unlikely. Homoglyph attacks and the recent Trojan Source exploit lean strongly towards preferring code source code to be as regular and simple as possible.