Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: Go 2: find a way to export uncased identifiers #22188
#5763 (comment) observes “It is very strange to use, say Z成本 or Jぶつける as identifiers.” In that issue we discussed potentially changing the default export rule, but as of #5763 (comment), which seemed to have general agreement, we decided against that.
Even so we do want to find a way to export uncased identifiers, or at least consider ways, in order to address the original observation.
This issue is for discussion of non-breaking ways to export uncased identifiers.
This has been discussed before, but to note it on this issue: one possible approach would be to designate a specific Unicode character, not otherwise available for use in identifiers, to designate the identifier as exported.
For example, if we use the character
This then leads to another decision point. We could treat the
In addition to what @ianlancetaylor said: There's also a third design choice (besides requiring the special Unicode character always for exported identifiers, or only inside the package that exports the identifier). The third choice is to only require the special Unicode character at the declaration; basically a marker indicating that the following (or perhaps preceding) identifier is exported. There's also an obvious drawback** with this choice which is that one won't be able to tell (at a use site) whether an identifier is exported or not by simply looking at it. ( ** In the past we have eschewed this idea).
Regarding the choice of the special Unicode character: One could chose
If we are contemplating a change to export rules anyway, we should evaluate whether the same mechanism could be used for fields of cgo-imported structs, as described in #13467.
As far as I can tell, the constraints to address that use-case are:
A distinguished Unicode character only satisfies those constraints if it is not required for field references within the same package.
maybe this can be solved in some other project's own coding rules
// if you don't understand the requirement and abstract the concepts very well and cant' come up with good names
// E for Export
// or use a Getter
some time some coder can't come up with a good name in English, this has nothing to do with the programming language.
variable or function names in Chinese are not used so much in source code. other part of source code are still not Chinese: if, for, func, return. you don't use variable or function names in Chinese in C, C++ too.