Skip to content
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 · 10 comments
Open

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

rsc opened this issue Oct 9, 2017 · 10 comments

Comments

@rsc
Copy link
Contributor

@rsc 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
Copy link
Contributor

@ianlancetaylor 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 package. 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
Copy link
Contributor

@griesemer 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
Copy link
Member

@bcmills 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
@lijhello
Copy link

@lijhello lijhello 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
Copy link

@Davidc2525 Davidc2525 commented Jan 17, 2019

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

@kstenerud
Copy link

@kstenerud kstenerud commented Mar 7, 2020

Why not just make go 2.x be explicit, using keywords like public and private to specify visibility? "Clever" hacks upon existing systems not designed for that purpose (e.g. letter case) are what cause these kinds of messes in the first place. Adding further hacks on top of the broken ones just makes it worse.

To support legacy code, you could make fields of unspecified visibility use the old, broken behavior so that code still compiles and runs as expected.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Mar 7, 2020

@kstenerud We believe that the fact that one can immediately tell by looking at an identifier whether it is exported or private is a feature. We don't consider it to be broken behavior.

In any case this is now so fundamental to Go code that it would not be feasible to change it at this point.

@beoran
Copy link

@beoran beoran commented Aug 5, 2020

In Oberon * or - were used as export marks, so using, for example . as the export mark is not unprecedented. (https://cseweb.ucsd.edu/~wgg/CSE131B/oberon2.htm) I feel that the go package system as well as the imports and exports are inspired by Oberon, but with the advantage that upper case identifiers are exported "automatically". Still, I think it is an omission that there can't be an explicit export mark as well. Furthermore, for interoperation between Go and other languages, it might be desirable to export a lower case identifier as well.

The fact that one can immediately tell by looking at an identifier whether it is exported or private is only of limited use, since that is only so at the local package level. If the identifier comes from another package, normally, if not using dot imports, it is immediately clear that an identifier is imported, thanks to the package prefix. Therefore I think that the '.' prefix to signify an exported identifier like @griesemer proposes is the best solution for this problem.

@dreamgonfly
Copy link

@dreamgonfly dreamgonfly commented Oct 20, 2020

Why not keyword "export"? It's readable, explicit, and understandable even for new comers. Please do not give more special characters special meanings, which is incomprehensible at first glance.

I also support @kstenerud 's opinion.

@beoran
Copy link

@beoran beoran commented Oct 20, 2020

Go is partially inspired on oberon-2, but it has a more C like syntax. Otherwise we would write begin in stead of { and end in stead of }, and pointer in stead of *. So special characters with special meaning is somewhat normal for Go.
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
10 participants
You can’t perform that action at this time.