proposal: Go 2: make the keyword 'map' optional

[kpym]

I was not able to figure out some case where removing the 'map' keyword create ambiguity.
Go do not have 'slice' keyword to define slices, why we need 'map' ?

var m [string]Vertex

m = make([string]Vertex)

evaluations := [string]int{"Hatim": 20, "Alex": 18}

or even

m = make([string][float64]Time)

looks to me without ambiguity.

IMO, the syntax without 'map' looks :

• unambiguous,
• shorter,
• more in harmony with the slice syntax ([]int vs [string]int vs map[string]int).

[changkun]

Duplicate of #36508

[kpym]

@changkun Not exactly, #36508 is to remove the keyword 'map', my proposal is to make it optional. The main argument to refuse #36508 is that this change is not backward compatible. But if the word 'map' becomes optional this will not break any code.

But thank you for pointing #36508, which I didn't know.

[ALTree]

IMO, the syntax without 'map' looks unambiguous

But... it's not? There's an obvious ambiguity with the array declaration syntax. This has also been pointed out in #36508. And that's a big price to pay for the privilege of saving literally 3 characters when declaring a map type.

[kpym]

@ALTree it depends about what ambiguity we are talking. From the point of view of the compiler there is no one : [foo]type is an array if foo is an integer value, and it is a map if foo is a type. From point of view of the reader the example could be ambiguous, but in this case the problem is somewhere else : if the reader could not understand if foo is an integer or a type may be the code is not well written and the naming conventions are not good enough.

In any case we can use the optional map keyword and introduce an array optional keyword to use in case we want to produce more readable code. But in 99% of the cases, like [10]string or [string]int there is no possible ambiguity for the reader.

It looks to me strange to want to keep map but to accept [foo]string in place of array[foo]string as obvious. Are there some reasons to keep map and not to have array keyword ? I understand that if one of the two words is mandatory the other is useless, but why we should have this asymmetry in the conventions ?

[dotaheor]

With the introduction of custom generics, I would like to see converting the map keyword to a builtin identifier (a builtin generic type).

[mvdan]

From the point of view of the compiler there is no one : [foo]type is an array if foo is an integer value, and it is a map if foo is a type.

Right now, the language is unambiguous when it comes to maps and arrays without type information. That is what the original thread was about.

Requiring type information to tell if a type expression is a map seems like a step in the wrong direction.

In any case we can use the optional map keyword and introduce an array optional keyword to use in case we want to produce more readable code.

Both of those changes would be language changes. Please note that you should fill https://github.com/golang/proposal/blob/master/go2-language-changes.md when proposing a language change.

[ianlancetaylor]

This seems to increase reader confusion for minimal benefit.

Separately, making map optional would be unusual. I can't think of any other Go construct that is optional. In Go, we're generally happy if there is one way to do something. We only add a second way if there is a clear benefit. I'm not seeing the benefit here.

[davecheney]

@kpym does

func f() [string]int

return a map or an array?

[kpym]

@davecheney [string]int is a map. Am I missing something, how [string]int could be an array ? And why we need func f() in this example to decide the type of [string]int ?

The only ambiguous case (for the reader, not for the compiler) that I have seen so far is [foo]type where foo could be an integer variable (or constant) or a type. But in this case I have the feeling that using map[foo]type to tell the user "be careful foo is a type not an integer" is not a good idea.

I'm very interested if somebody can show me another ambiguous case.

[kpym]

@ianlancetaylor Is var mandatory ? We can do

var a string
a = "initial"

or

var a = "initial"

or

a := "initial"

We can also discuss how mandatory is string in the previous example, or how mandatory is new in general, or many other cases where the construction is not unique.

[davecheney]

@kpym

@davecheney [string]int is a map. Am I missing something, how [string]int could be an array ?

https://play.golang.org/p/1p6DNYj0Lbs

Without the map[ prefix the go parser would need a symbol table to know if string is a type declaration or a constant

[kpym]

@davecheney

https://play.golang.org/p/1p6DNYj0Lbs

Without the map[ prefix the go parser would need a symbol table to know if string is a type declaration or a constant

It looks like the compiler already knows that string is not a type in this case :

https://play.golang.org/p/ES0oBp3F3li

So in this particular case where string is an integer variable (and not a type any more) the compiler should consider [string]int as an array. One more time the ambiguity is not for the compiler but for the reader, and is not coming from the missing map keyword but from the fact that a programmer has named an integer variable string. And we can't do nothing against this strange behavior of the programmers ;)

[mvdan]

@kpym as said before, then you're relying on the type system to realise if a type expression is a map or an array. That's a significant step backwards.

Also, a reminder that there's a form you should fill for language changes, which I linked above.

[dominikh]

One more time the ambiguity is not for the compiler but for the reader

The ambiguity is for the parser.

[ianlancetaylor]

@kpym

Is var mandatory ?

There are other ways to write variable declarations, but var is not optional in the sense that you are suggesting that map should be optional. You can't write the exact same statement with or without var.

It's true that there are multiple ways to declare variables. There are reasons for that. As I said, we only add a second way if there is a clear benefit. I'm not seeing the benefit here.

[ianlancetaylor]

For language change proposals, please fill out the template at https://go.googlesource.com/proposal/+/refs/heads/master/go2-language-changes.md .

When you are done, please reply to the issue with @gopherbot please remove label WaitingForInfo.

Thanks!

[kpym]

It seems that no one agrees with me on this subject.
Probably the best thing to do is to close it and not waste any more of everyone's time on this issue.
Sorry for this seemingly bad idea.
So, IMO, you can feel free to close this topic.
Thank you for considering my request.

[mvdan]

If you're not going to fill the template linked above, I do agree that we should close this.