Generic syntax suggestions

[Wu Kulics]

Dear Go Design Team:

 

Recently I explored a new generic syntax in the [Feel](https://github.com/kulics-works/feel) language that I designed, because Feel borrowed a lot of grammar from Go, so this Generic syntax may also have some reference value for Go.

 

The `identifier<T>` problem is that it conflicts with comparison operators and also bit operators, so I don't agree with this design.

 

Scala's `identifier[T]` has a better look and feel than the previous design, but after resolving the above conflict, it has a new conflict with the index design `identifier[index]`.

For this reason, the index design of Scala has been changed to `identifier(index)`. This does not work well for languages ​​that already use `[]` as an index.

 

In Go's draft, it was declared that generics use `(type T)`, which will not cause conflicts, because `type` is a keyword, but the compiler still needs more judgment when it is called to resolve the` identifier(type)(params) `. Although it is better than the above solutions, it still does not satisfy me.

 

By chance, I remembered the special design of method invocation in OC, which gave me inspiration for a new design.

 

What if we put the identifier and the generic as a whole and put them in `[]` together?

We can get the `[identifier T]`. This design does not conflict with the index, because it must have at least two elements, separated by spaces.

When there are multiple generics, we can write `[identifier T V]` like this, and it will not conflict with the existing design.

 

Substituting this design into Go, we can get the following example.

E.g.

 

This looks very clear.

 

Another benefit of using `[]` is that it has some inheritance from Go's original Slice and Map design, and will not cause a sense of fragmentation.

 

We can make a more complicated example

 

This example still maintains a relatively clear effect, and at the same time has a small impact on compilation.

 

I have implemented and tested this design in Feel and it works well.

 

I think Go’s current generic syntax will eventually render the code too many `()`, so that the readability is destroyed when coding, and the goal of simplicity is lost.

 

In addition to the way of `[identifier T]`, I have also tested the syntax of `<identifier T>`. After doing some special processing on `>>`, it can also avoid ambiguity. This is closer to the mainstream `identifier<T>` grammar, and it is easier to lower the learning threshold for users of other languages.

 

Thank you very much for reading this email, I hope it will bring reference value to the Go community.

[Ian Lance Taylor]

Thanks for the suggestion.  I feel like I've seen this somewhere before, perhaps also from you.

For me personally, it doesn't feel quite right, for the reasons shown in your map and slice rewrite.  In Go we write []int, not [slice int], and we write map[int]int, not [map int int].  We can talk about what it looks like if we write the latter variants, but it's years too late to change the language in that way.  So while the suggestion does seem workable, it doesn't feel quite like Go syntax to me.

But I would be happy to hear other opinions.  Thanks for writing it.

Ian

[Wu Kulics]

Thank you for your reply. I did mention this suggestion on [Github](https://github.com/golang/go/issues/36457) before, but then everyone's focus was on the backend.

 

In the previous map and slice examples, [slice int] and [map int int] are just for reference. I think this syntax is very similar to []int and map[int]int, which is very suitable for everyone to understand the generic design of Go, we do not need to change the previous syntax.

 

The design of identifier(type T) will lead to too many () in the end, especially when defining the receiver function. This change in readability undermines Go's original goal. We still want to see simple and clear code on Go, not many ().

 

I have studied in detail the generic design of Go proposed by others. So far, [identifier T] is the only solution that to avoid <>, without increasing the number of characters, without adding keywords, without ambiguity, without reducing readability, without increase the workload, and continues the original grammatical design.

 

I hope this design can attract enough attention, or at least it can cause some discussion.

 

发件人: Ian Lance Taylor <ia...@golang.org>
日期: 2020年6月20日 星期六 上午3:03
收件人: Wu Kulics <kul...@outlook.com>
抄送: "golan...@googlegroups.com" <golan...@googlegroups.com>
主题: Re: [go-nuts] Generic syntax suggestions

[Denis Cheremisov]

I like it. Poor VSCode users will suffer from the current approach and all these ((())))) – this thing can't even highlight types of function parameters. Your variant is a lot (I mean a LOT) more readable 

Also, []T and map[K]V does not look consistent, so I don''t think this is a true valid reason:

In Go we write []int, not [slice int], and we write map[int]int, not [map int int].

суббота, 20 июня 2020 г., 11:02:05 UTC+3 пользователь Wu Kulics написал:

[Denis Cheremisov]

PS

Also, []T and map[K]V does not look consistent, so I don''t think this is a true valid reason:

I didn't mean they are inconsistent. They just don't look consistent at the first glance. 

суббота, 20 июня 2020 г., 19:06:14 UTC+3 пользователь Denis Cheremisov написал:

[Wu Kulics]

Hi, I recently came up with a new idea.

 

I've tried a new approach in my language, before I used `[]` to wrap type names and type arguments, but now I've found that I can remove the `[]` and add `()` to distinguish when it can't be parsed, which is also an interesting solution, very similar to the way chan is written in the go language.

 

Show a simple comparison.

 

 

 

 

 

发件人: Ian Lance Taylor <ia...@golang.org>
日期: 2020年6月20日 星期六 上午3:03
收件人: Wu Kulics <kul...@outlook.com>
抄送: "golan...@googlegroups.com" <golan...@googlegroups.com>
主题: Re: [go-nuts] Generic syntax suggestions

 

On Fri, Jun 19, 2020 at 10:24 AM Wu Kulics <kul...@outlook.com> wrote: