proposal: spec: export uncased identifiers like 日本語

[leo-liu]

In go (now v1.1.1), an identifier is exported only if it starts with a character in
Unicode class "Lu" (uppercase letter).

The feature works fine for Western languages, but fails for CJK languages. All CJK
characters are letters but they are not uppercase. Therefore, these are not exported:

    var 成本 int = 5        // Chinese ideograph
    func ぶつける() { ... } // Japanese Hiragana (they are indeed letters)

It is very strange to use, say Z成本 or Jぶつける as identifiers.

I don't know how to properly control the permission. But at least I think it is
preferable to use CJK characters as *uppercase* letters, if we have no other choices
(more keywords, etc.)

[cznic]

Comment 1:

IMHO this is working as intended. Also note that such change would not be backward
compatible, ie. it could suddenly export things which were previously package private
(safe from being accessed from other packages).
PS: My native language is also not English, but I, for one, would never ever use a non
English identifier in my code, except perhaps for some occasional Greek letters in math
stuff.
I suggest tag #Unfortunate

[leo-liu]

Comment 2:

I guess there won't be much old code which uses CJK identifiers, if we support it early.
I myself rarely use non-English identifiers either.  However, I know that CJK
identifiers are often used in some business domain (no proper English translation
exists), in C# and Java.
Unicode identifier support is good, but it may be more useful for CJK languages if we
change a bit.

[ianlancetaylor]

Comment 3:

In language that have no upper/lower case distinction, we need a
special case for exported symbols or a special case for non-exported
symbols.  The current language has a special case for exported
symbols.  I really don't know what is better.  As far as I know there
has never been a clear consensus either way among people who, unlike
me, speak those languages, so we've just muddled along with the
current approach.
As you say, this can not change until Go 2 anyhow.  But if there is a
clear consensus for Go 2, then it could certainly change then.

[rsc]

Comment 4:

We have heard from other Go programmers who are native speakers of these
languages who have suggested to leave things as they are.
Our suggestion at least for the lifetime of Go 1 (and perhaps beyond) is to
use "X" as the canonical exporting prefix in these cases.
Russ

[bradfitz]

Comment 5:

Labels changed: added go2, priority-someday, removed priority-triage.

Status changed to Thinking.

[chai2010]

Comment 6:

There are some discuss about this topic:
https://groups.google.com/forum/#!topic/golang-china/h_vxbPHaIvw/discussion
I can accept the current exported identifiers rule.

[gopherbot]

Comment 7 by bronze1man:

My native language is Chinese, I never use Chinese as variable name.
Sometimes, you need translate some Chinese concept into English just for a variable name.
I think it is good idea to support Chinese variable name as export name.

[bradfitz]

Comment 8:

Issue #6745 has been merged into this issue.

[bradfitz]

Comment 9:

Issue #6745 has been merged into this issue.

[rsc]

Comment 10:

Labels changed: added go1.3maybe.

[rsc]

Comment 11:

Labels changed: added release-none, removed go1.3maybe.

[rsc]

Comment 12:

Labels changed: added repo-main.

[robpike]

Comment 13:

A solution that's been kicking around for a while:
For Go 2 (can't do it before then): Change the definition to "lower case letters and _
are package-local; all else is exported". Then with non-cased languages, such as
Japanese, we can write 日本語 for an exported name and _日本語 for a local name.
This rule has no effect, relative to the Go 1 rule, with cased languages. They behave
exactly the same.