[Proposal] Support emoji for variable name 🍍🐶🐮🚀

[NicolasDorier]

To my disappointment, variable names does not support all unicode characters

How to reproduce

public enum ThreeStateBool
{
    🍍,
    Yes,
    No
}

Expected

The code build and I can use fruits to better communicate code requirements via variable names.

Actual

A build error

Error	CS1056	Unexpected character '�'	

I am using C# 8.0.

[ufcpp]

see #1742 (comment)

However, 🍍 can not be an identifier because its category is Other Symbol.

[NicolasDorier]

Ah what a disappointment :( closing as dup then.

[NicolasDorier]

Reopening as this is a different request on valid unicode for variable name.

This has been implemented in g++ 10. Fixing issue https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224

g++ 10.1.1 + binutils 2.34.0.20200522)

[HaloFour]

I, for one, would gladly welcome any language changes that would include more 🥓.

Swift is another language that allows for characters such as emoji in identifiers:

let 🐶🐮 = "dogcow"
let ＃🚀 = "Hashrocket"
NSLog(＃🚀)

[svick]

Note that the C# spec (mostly) attempts to follow Unicode Standard Annex #31: Unicode Identifier and Pattern Syntax, which does not allow emoji.

[Unknown6656]

Note that the C# spec (mostly) attempts to follow Unicode Standard Annex #31: Unicode Identifier and Pattern Syntax, which does not allow emoji.

Thank heavens for that!
I already see some autonomous vehicles crashing into walls due to programming bugs in the future, because some Zoomer-kid used the wrong sushi colour in his code base ......

Emojis in strings are all fine (I still hate them, but that is completely beside the point), however, imagine trying tracking down a bug for hours on end only because your field named :santaclaus: has the wrong gender or skin colour. IMO, C# code (meaning symbol names - not string literals) should be restricted to UTF-16.

[Zabadam]

I see your point, but I counter that if you are using that many similar yet different emoji, you may already have easily-confused UTF-16 variable names in your programming dialect (like missing an 's' because this is an Items[] and not an Item).

[ufcpp]

What exactly do you want to use as identifiers? spec needed.

FYI:

• Rust: ASCII only
• Go: Letters and digits only
• Java: Similar to C#, basically follows UAX #31
• Swift: All characters outside BMP are identifier-character. This includes Not-Assigned characters, Variation Selecters, Musical Symbols, and Arrows
• Emoji data: If you want to use only Emoji instead of all non-BMP characters, IsIdentifierStartCharacter and IsIdentifierPartCharacter need additional data table which is not as simple as general category. Moreover, # (U+0023) and * (U+002A) are included in Emoji.
• Emoji EBNF and Regex: Some Emoji consist of multiple codepoints. For instance, 👩🏼‍👨🏽‍👦🏼‍👧🏽 consist of 1F469 1F3FC 200D 1F468 1F3FD 200D 1F466 1F3FC 200D 1F467 1F3FD (encoded 41 bytes in UTF-8). Some sequence include BMP characters (e.g. 👨‍⚕️ = 1F468 200D 2695 FE0F) and need more data table.
  • In C# identifier spec, any formatting characters are removed and ZWJ (U+200D) is a formatting character. 👩🏼‍👨🏽‍👦🏼‍👧🏽 and 👩🏼👨🏽👦🏼👧🏽 (ZWJ removed from 👩🏼‍👨🏽‍👦🏼‍👧🏽 ) are identical in C#.
  • Subdivision flags such as Flag: Scotland consist of 🏴 + formatting Tag characters. Thus all subdivision flags are identical to 🏴 (Black Flag)

[sylveon]

FWIW C++ supports them: https://godbolt.org/z/P37427

The list of allowed characters in the standard seems to allows ZWJ as well

[CyrusNajmabadi]

i would champion an effort to get C# to support any/all identifiers that match the unicode identifier annex. If emojis are part of that annex, then that would naturally fall out. If they are not, i wouldn't support or do work to make them part of the language for identifiers.

[ufcpp]

Emoji is not. Most of Emoji are Other Symbol.

[CyrusNajmabadi]

Good to know. Not championing this issue then. Thanks!

[NicolasDorier]

Apparently Clang 10 support it.

[NicolasDorier]

@ufcpp I think the same as C++ would be perfect. http://eel.is/c++draft/lex.name#1

[NicolasDorier]

I admit this was initially for fun, but the discussion is actually interesting.
C++ supports it only until recently (clang 10.0 and g++ 10) so I think this is relevant.

[Serentty]

@Unknown6656

IMO, C# code (meaning symbol names - not string literals) should be restricted to UTF-16.

I don't know what you mean by this. UTF-16 can encode emoji, or else C# strings wouldn't be able to hold them. UTF-16 uses a single 16-bit number for BMP characters, and two 16-bit numbers for characters outside the BMP. If you mean that you think identifiers should be restricted to the BMP, then I strongly disagree. The BMP/non-BMP distinction is purely historical and has nothing to do with suitability for identifiers or how “wacky” a character is. There are multiple living languages that are written in characters partially or entirely outside of the BMP.

As for whether emoji should be allowed in variable names, I think the Unicode recommendations for identifiers are very sound. There's a reason that $ isn't allowed in identifiers, and emoji fall into a similar logical category. The Unicode recommendations are very logical and consistent. For example, they consider numbers in other numeral systems to work along the same logical principles as the Arabic numerals 0 through 9 when it comes to where they can occur in identifiers. I wouldn't agree with further deviating from a standard which has had a lot of effort and thought put into it.

[NicolasDorier]

. There's a reason that $ isn't allowed in identifiers, and emoji fall into a similar logical category. The Unicode recommendations are very logical and consistent.

Where is the reasoning?

[Serentty]

The way I see it, the reasoning is this: languages usually don't allow “symbols” in identifiers because they usually use them as part of the syntax of the language instead. Think of all the operators in C# for example. So within ASCII or EBCDIC or whatever old encoding with a small set of characters, generally programming languages allow the set of characters which can be used to write words to be used in identifiers, and reserve other characters for use by language syntax without the need for whitespace delineation. Often numbers are considered okay, as long as they're not at the start of an identifier so there's no confusion with literals.

Now, when we move beyond these old encodings into Unicode, what do we do? The approach that the standard that C# follows takes is essentially just to extend that pattern out, and try to be as consistent as possible. Characters which are used to write words are allowed, just as before. Characters which are used as symbols, punctuation, whitespace, or control are not. Characters which are used only in the writing of numbers in other (human) languages are allowed, but not at the beginning of an identifier. It has a logical consistency to it that you lose if you just say: “This character is really cute, therefore I want to name a class with it.”

If you want fun names, options are still open without emoji. You can name your variables in Ancient Egyptian written in hieroglyphs if you want. Or at least you will be able to once the issues around non-BMP identifiers are fixed in Roslyn.

[chrisaut]

Personally I don't care for this. I'm not against it being in the language if it were somehow "free" in terms of cost to get it to work, although I would certainly ban any use of emoji in any code base my team works on.

But it's not free to get it to work, I think the team's time can be spend on much more valuable additions.

[viniciusvillas]

Personally I don't care for this. I'm not against it being in the language if it were somehow "free" in terms of cost to get it to work, although I would certainly ban any use of emoji in any code base my team works on.

But it's not free to get it to work, I think the team's time can be spend on much more valuable additions.

I second that!

[CyrusNajmabadi]

Even if free, I would reject this proposal. So far I haven't seen any compelling cases where this would be valuable or appropriate, and I've seen a lot of cases that show why I would not want this in the language.

[mcattle]

So far I haven't seen any compelling cases where this would be valuable or appropriate, and I've seen a lot of cases that show why I would not want this in the language.

catch (Exception 💩)

[jmarolf]

You can already do this

catch (Exception ಠ_ಠ)

So I dunno about the value emoji bring

[kyoyama-kazusa]

You can already do this

catch (Exception ಠ_ಠ)

So I dunno about the value emoji bring

var _ = 0;
return ~~(0 ^ _ ^ 0);

[Daynvheur]

I already see some [...] programming bugs in the future, because some Zoomer-kid used the wrong sushi colour in his code base ......

That's something already possible today with variable name suffixed by an automatic increment, something like Button5+Button23+Button42+..., that are semantically indistinguishables. Bad naming would still be a pain, emoji variations would only be a step anyone could acclimate with.

Side note: I didn't find any color variation for the 🍣 sushi emoji, but it would be a nice thing for Intellisense to check for emoji
possible misreferences, something like "You used 💔, did you mean ❤️ instead?".

[masonwheeler]

I admit this was initially for fun, but the discussion is actually interesting.
C++ supports it only until recently (clang 10.0 and g++ 10) so I think this is relevant.

"Well, C++ did it" is generally a pretty good argument in favor of not doing something, particularly when the majority of other languages are not doing the same thing. A lot of the success of the CLR and the C# language is built on learning from C++'s mistakes rather than repeating them.

[laicasaane]

Interesting idea but certainly no. Please think about people who are visually impaired. Explicit and long names are always better.

[NathanielArmer]

I support this request because I think it would add a lot of value when trying to teach the langue to beginners, or even as a fun way to introduce new features to existing developers.

It's not necessarily a good practice for production code, but not all code is production code. Expressiveness is an important feature of a language, and Emoji are a powerful way of expressing certain idea's.

[RenderMichael]

It's not necessarily a good practice for production code, but not all code is production code.

If this gets implemented, it would have to be paired with an analyzer and a rule to disallow emojis (preferably disallowed by default). Given those conditions, I think it's not a bad idea, but at that point the implementation cost probably skyrockets (someone with an understanding of implementing Roslyn analyzers could determine exactly how costly it would be).

[yaakov-h]

That analyser would be less than a day's work for someone experienced with them. Compared to language changes or compiler changes, analysers are trivial.

[jnm2]

If I remember @CyrusNajmabadi's comments about studies they did, it's a day's work for someone who hasn't worked with Roslyn analyzers before and more like minutes or hours for someone who has.

[shayded-exe]

I want this exclusively so I can do

throw new 🤷‍♂️();

[Daynvheur]

You would need something like:

using 🤷‍♂️ = System.Exception;

Which I do agree would be awesome.

[ArtVandelay101]

catch (Exception ☠️)

[KennethHoff]

catch (☠️)

[ArtVandelay101]

This proposal is just for variable names. I think you are looking for this one https://www.emojicode.org 😃

[KennethHoff]

The only example he gave is not a variable though 😭

[Daynvheur]

To be in par with #3490 (comment):

using ☠️ = System.Exception;
//...
catch(☠️); // catch(System.Exception);

[Kerrick]

C++ isn't the only language that supports emoji identifiers. You can also do it in Ruby.

kerrick@💻👨🏻☝🏻 ~ % irb
irb(main):001> RUBY_VERSION
=> "3.4.2"
irb(main):002> 🧙 = "Elanduilinilithar of house Bronsuiligifinabinen"
=> "Elanduilinilithar of house Bronsuiligifinabinen"
irb(main):003> puts 🧙
Elanduilinilithar of house Bronsuiligifinabinen
=> nil

[AndersKehlet]

I need this for interop with F#

type ``🤔``<'T> = Option<'T>

Well, I say "need", but it's more of a deep yearning that I don't quite understand.