New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: Go 2: find a way to export uncased identifiers #22188

Open
rsc opened this Issue Oct 9, 2017 · 5 comments

Comments

Projects
None yet
7 participants
@rsc
Copy link
Contributor

rsc commented Oct 9, 2017

#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.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

ianlancetaylor commented Oct 10, 2017

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 $, then people would write $成本 to indicate that this identifier is exported. $ is just an example, it could instead be or or pretty much anything.

This then leads to another decision point. We could treat the $ as a required part of the identifier, which then means that people will write p.$成本 to refer to the symbol from a different pacakge. The effect is that we will see .$ everywhere; it almost becomes a token in itself. Or, we could say that the $ is only required for references within the package where the symbol is defined, and that for references from a different package the $ is implied. After all, if the $ were not there, the symbol could not be referenced from a different package anyhow. We would then have to consider the interaction with method names and interface satisfaction; there is an obvious set of rules but is it clear enough for the reader?

@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Oct 10, 2017

@griesemer

This comment has been minimized.

Copy link
Contributor

griesemer commented Oct 10, 2017

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 . (period). Inside a package p that declares the exported identifier, say 成本, one would have to write .成本. Inside a package that imports package p one would continue to write p.成本. This would be pretty natural in imported packages, and fairly unobtrusive (but still visible) in the declaring package.

@bcmills

This comment has been minimized.

Copy link
Member

bcmills commented Oct 18, 2017

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:

  1. When used to export all of the fields of a struct type, aliases of that struct type defined in different packages must be identical.
  2. Within a package, the use of a struct field exported by this mechanism must not require a distinguished prefix.

A distinguished Unicode character only satisfies those constraints if it is not required for field references within the same package.

@ianlancetaylor ianlancetaylor changed the title spec: find a way to export uncased identifiers proposal: Go 2: find a way to export uncased identifiers Mar 21, 2018

@gopherbot gopherbot added the Proposal label Mar 21, 2018

@linuxjh

This comment has been minimized.

Copy link

linuxjh commented Jun 1, 2018

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
var E_成本1 double
var E_成本2 double
var E_成本3 double

// or use a Getter
func Get_成本() double

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.

@Davidc2525

This comment has been minimized.

Copy link

Davidc2525 commented Jan 17, 2019

if they come to place $ to declare a variable, I will hate to go

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment