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: remove map from keywords #36508
Go 1 is tightly designed with 25 keywords:
All keywords have their value and orthogonal except the
Comparing to these three definitions,
I propose to remove
I don't agree with this proposal. When I read
But with your proposal. it would be ambiguous to the reader, as it could also be
I am the one who gave thumb up, so I have do argue why. Because I love what Mr. Griesemer showed 2006. If we can declare our Indexes on our own, surely we can remove map from the core, like complex numbers. And yes, go fix can and should fix this.
For language change proposals, please fill out the template at https://go.googlesource.com/proposal/+/bd3ac287ccbebb2d12a386f1f1447876dd74b54d/go2-language-changes.md .
When you are done, please reply to the issue with
Would you consider yourself a novice, intermediate, or experienced Go programmer?
What other languages do you have experience with?
Would this change make Go easier or harder to learn, and why?
Easier. I consider this makes Go with fewer keywords, compact.
Has this idea, or one like it, been proposed before?
No, to my knowledge.
If so, how does this proposal differ?
Who does this proposal help, and why?
All Go users. Type less, and more apparent to the meaning of the data type.
Take this example:
Hash table can be considered as a "Multidimensional Array".
Is this change backward compatible?
No. But Yes, with
Breaking the (Go 1 compatibility guarantee)[https://golang.org/doc/go1compat] is a large cost and ## requires a large benefit.
Or we do not do anything with a deprecated way of writing map:
Show example code before and after the change.
It is illustrated before.
What is the cost of this proposal? (Every language change has a cost).
Developer need slightly reconsider
How many tools (such as vet, gopls, gofmt, goimports, etc.) would be affected?
What is the compile time cost?
Faster since map can be considered as a multidimensional array.
What is the run time cost?
Can you describe a possible implementation?
Yes. Production rule:
Do you have a prototype? (This is not required.)
How would the language spec change?
Orthogonality: how does this change interact or overlap with existing features?
Is the goal of this change a performance improvement?
It might be in the future for compiler optimization.
If so, what quantifiable improvement should we expect?
Less binary size, less compile time, etc.
How would we measure it?
The measurement already exists in the current Go source.
Does this affect error handling?
If so, how does this differ from previous error handling proposals?
Is this about generics?
Might be related, because generics can implement a map package.
If so, how does this differ from the the current design draft and the previous generics proposals?
The proposal is some interesting, so I would expand it a little. I have no opinions on the proposal though.
I would expand it to the
If we can think it as there were originally the
So, the donations are quite consistent:
It looks Go authers had considered the extension for future custom generics.