Proposal: Go 2: Make Generics usage more accessible #39331
Labels
FrozenDueToAge
generics
Issue is related to generics
LanguageChange
Suggested changes to the Go language
Proposal
v2
An incompatible library change
Milestone
So I am very new to Go (literally started learning day before yesterday) before I stumbled upon lack of generics and years of discussion over it. It would take me days and probably months to catch up to all the discussions and proposals.
So I am writing this without knowing if this has already been discussed and also without knowing full history of go. I am also not sure if this is right place (and right mode) to make this suggestion, there are just so many proposals, blogs, discussions scattered around multiple places.
I have only read this blog on generics and based on that I have below suggestion -
Have we considered using some other syntax instead of parenthesis
(
and)
to define generics?Why?
Because parenthesis are used to pass arguments to a function and it gets confusing if used to define generic type specially because its used just before actual arguments.
For example here is the generic Reverse function example from the blog -
Focus on
Reverse(int)(s)
. This looks all good. But what happens if its like thisReverse(foo)(s)
. Well by just reading this line I can't make out whetherfoo
is a type or a variable defined somewhere above in my program.Reverse
could now be a function that returns a function which takes another parameter (func Reverse(a int) func([]int) int
) andfoo
can just be an integer defined somewhere above (don't go into integrities of why Reverse will accept int, that is not the point, this is just to demonstrate). To understand which it is I have to either scan through my code to know whatfoo
is or go to the definition ofReverse
function.The point is that this is not ambiguous to compiler but it is to the user. At first glance it is not clear what it is and user will have to pay special attention to it.
Another similar example of hard to read is
func Reverse (type Element) (s []Element)
. The first time I read it I thoughtReverse
is a function which has a parameter calledtype
of typeElement
and returns a named values
of type[]Element
. Why because I had just completed the golang tour which has very similar lookingsplit
function. It was only when I read it second time that I noticed thattype
is a reserved word and cannot be the parameter name.Again this is not problem for compiler but user has to pay special attention here not to misunderstand. I know the IDE will probably do correct syntax highlighting and make it more obvious is both the cases but still this is not something language should depend upon.
I know this may not be a problem with everyone and others would have more attention to detail. But since I faced it I thought to have a discussion on potential improvement in this.
The proposal is to make the generics visually distinct from parameters/argument. Generics are used just before parameters/arguments and so should look different from them so when scanning through a code I don't have to pay special attention to distinguish between them.
A potential solution could be to use angle bracket for generics
< >
.So the above example would become -
Why angle brackets?
go
so its visually distinct.I love the fact how Go is designed to be easy to use. All the features, syntax, concepts are orthogonal which makes it really easy to both read and write Go code.
The text was updated successfully, but these errors were encountered: