I don't agree with this proposal. When I read [foo]string, right now it's unambiguous; foo must be a constant like const foo = 10; var _ [foo]string, thus meaning an array.

But with your proposal. it would be ambiguous to the reader, as it could also be type foo int; var _ [foo]string, thus meaning a map.

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.
This would reduce the size of applications not using map. This would also open a door for SSE optimizations, 'cause data (ElementType) and index (KeyType) and all of its methods are known.
For me this is a thumb up, though it is strange at first look.

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 @gopherbot please remove label WaitingForInfo.

Thanks!

@maj-o, can you explain why we can't achieve the same level of optimization at compile time, please?

Hey, just wondering, maybe when generic became a thing, map can then be supported through a package rather than a builtin keyword? (Move first-class map to a package?)

@niruix Yes, a good generics implementation would support writing map as a package. That could be done with the current design draft, for example.

But the keyword version is still going to be more convenient to use.

Would you consider yourself a novice, intermediate, or experienced Go programmer?

Experienced.

What other languages do you have experience with?

C/C++

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?

Not applicable

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:

map[string]map[string]map[string]map[string]string

=>

[string][string][string][string]string

and this

// this remains to be an array.
const foo = 10; var _ [foo]string

// changing the meaning of foo, of course, will change the meaning of var.
type foo int;   var _ [foo]string 

Hash table can be considered as a "Multidimensional Array".

Is this change backward compatible?

No. But Yes, with go fix.

Breaking the (Go 1 compatibility guarantee)[https://golang.org/doc/go1compat] is a large cost and ## requires a large benefit.

Not breaking. go fix quickly fix everything.

Or we do not do anything with a deprecated way of writing map:
map[string]string continues to work, but will be removed in the future.
[string]string is recommended.

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?

go fix easily fix everything.

What is the compile time cost?

Faster since map can be considered as a multidimensional array.

What is the run time cost?

No change.

Can you describe a possible implementation?

Yes. Production rule:

ArrayType = "[" ArrayLength "]" ElementType .
SliceType = "["             "]" ElementType .
MapType   = "["   KeyType   "]" ElementType .

Do you have a prototype? (This is not required.)

No.

How would the language spec change?

Again:

ArrayType = "[" ArrayLength "]" ElementType .
SliceType = "["             "]" ElementType .
MapType   = "["   KeyType   "]" ElementType .

Orthogonality: how does this change interact or overlap with existing features?

No changes.

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?

No.

If so, how does this differ from previous error handling proposals?

No.

Is this about generics?

Might be related, because generics can implement a map package.
In this case, the proposal can be remove map from Go data types.
But this is not the intention of this proposal and should be in a separate issue.

If so, how does this differ from the the current design draft and the previous generics proposals?

No.

@gopherbot please remove label WaitingForInfo

The proposal is some interesting, so I would expand it a little. I have no opinions on the proposal though.

OP said:

All keywords have their value and orthogonal except the map which dedicated to a hash table data structure but also share similarities array and slice, according to the language specification:

ArrayType   =                    "[" ArrayLength "]" ElementType .
SliceType   =                    "["             "]" ElementType .
MapType     =              "map" "["   KeyType   "]" ElementType .

I would expand it to the chan keyword too:

ArrayType   =                    "[" ArrayLength "]" ElementType .
SliceType   =                    "["             "]" ElementType .
MapType     =              "map" "["   KeyType   "]" ElementType .
ChannelType = ( "chan" | "chan" "<-" | "<-" "chan" ) ElementType .

If we can think it as there were originally the array and slice keywords,
the above will be denoted as:

ArrayType   =            "array" "[" ArrayLength "]" ElementType .
SliceType   =            "slice" "["             "]" ElementType .
MapType     =              "map" "["   KeyType   "]" ElementType .
ChannelType = ( "chan" | "chan" "<-" | "<-" "chan" ) ElementType .

So, the donations are quite consistent:

• the last generic type is not enclosed in [].
• the next to last generic type, if it exists, is enclosed in [].

It looks Go authers had considered the extension for future custom generics.

This change would break essentially all existing Go code, and would invalidate essentially all existing documentation. We can automatically fix the code, but not the documentation. That is a heavy cost. The benefit of removing a keyword doesn't seem worth it.

The resulting code is generally less readable, as it becomes less clear whether a type is a map or an array.

This proposal does not have much support based on emoji voting.

For these reasons, this is a likely decline. Leaving open for four weeks for final comments.

No further comments, so closing.