-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: list symbols that don't require package name #33070
Comments
One problem in your suggest:If follow three cases in the same project, there will be a burden for the code reader and make it harder to copy and paste small part of code between files:
|
This comment has been minimized.
This comment has been minimized.
@bronze1man Thank you, but I don't think that is a problem. |
Related to #29036. |
You can get a similar effect by writing, after the imports, type IOReader = io.Reader (For a function, use a The requirement of writing a package name is not a major complaint about Go. In fact, many people think it is a feature. I'm not sure it's worth changing the language to add a shorter way of doing something that you can already do, and that not a lot of people want to do anyhow. Speaking only for myself. |
@ianlancetaylor Thank you. But I don't think it is a feature and the shorter way of coding is great. |
Maybe it would be better to just allow omission of package name for all symbols that can be resolved unambiguously. Like so:
|
@yekhlakov Hello, I like that too. But trust me they will never let that happen! |
As discussed above, there are other way to do this. We don't need a new syntax for it. And this proposal does not have strong support based on emoji voting. Therefore, this is a likely decline. Leaving open for four weeks for further comments. |
There were no further comments. |
Problem:
In many case, the last word of the import path is not the real package name. So, it is kind of confusing here ! And write the package name over and over is not the best way to write or read code.
So I bring a proposal:
Proposal1:No new keywords come in, no break code.Proposal2:
Proposal1 is probably confusing and not accepted commonly.
This is totally copied from TypeScript
The text was updated successfully, but these errors were encountered: