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: make the keyword 'map' optional #41244

Closed
kpym opened this issue Sep 6, 2020 · 18 comments
Closed

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

kpym opened this issue Sep 6, 2020 · 18 comments

Comments

@kpym
Copy link

@kpym kpym commented Sep 6, 2020

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

@changkun changkun commented Sep 6, 2020

Duplicate of #36508

@kpym
Copy link
Author

@kpym kpym commented Sep 6, 2020

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

@ALTree ALTree commented Sep 6, 2020

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
Copy link
Author

@kpym kpym commented Sep 6, 2020

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

@dotaheor dotaheor commented Sep 6, 2020

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

@mvdan mvdan added the WaitingForInfo label Sep 6, 2020
@mvdan
Copy link
Member

@mvdan mvdan commented Sep 6, 2020

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.

@mvdan mvdan added the LanguageChange label Sep 6, 2020
@martisch martisch added the Go2 label Sep 6, 2020
@martisch martisch changed the title Proposal : make the keyword 'map' optional Proposal: Go2: make the keyword 'map' optional Sep 6, 2020
@gopherbot gopherbot added this to the Proposal milestone Sep 6, 2020
@gopherbot gopherbot added the Proposal label Sep 6, 2020
@ianlancetaylor ianlancetaylor changed the title Proposal: Go2: make the keyword 'map' optional proposal: Go 2: make the keyword 'map' optional Sep 6, 2020
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Sep 6, 2020

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

@davecheney davecheney commented Sep 6, 2020

@kpym does

func f() [string]int

return a map or an array?

@kpym
Copy link
Author

@kpym kpym commented Sep 7, 2020

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

@kpym kpym commented Sep 7, 2020

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

@davecheney davecheney commented Sep 7, 2020

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

@kpym kpym commented Sep 7, 2020

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

@mvdan mvdan commented Sep 7, 2020

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

@dominikh dominikh commented Sep 7, 2020

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

The ambiguity is for the parser.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Sep 7, 2020

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

@ianlancetaylor ianlancetaylor commented Sep 7, 2020

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
Copy link
Author

@kpym kpym commented Sep 7, 2020

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

@mvdan mvdan commented Sep 7, 2020

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

@mvdan mvdan closed this Sep 7, 2020
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.