proposal: Go 2: A compatible generics syntax

[kulics]

Go 2 Generic Design

Recently I explored a new generic syntax in the 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 theidentifier(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.

type [Item T] struct {
    Value T
}

func (it [Item T]) Print() {
    println(it.Value)
}

func [TestGenerics T V]() {
    var a = [Item T]{}
    a.Print()
    var b = [Item V]{}
    b.Print()
}

func main() {
    [TestGenerics int string]()
}

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.

[]int  ->  [slice int]

map[string]int  ->  [map string int]

We can make a more complicated example

var a map[int][]map[string]map[string][]string

var b [map int [slice [map string [map string [slice string]]]]]

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 this design has a certain reference value and may be worthy of discussion.

[ianlancetaylor]

Thanks. Right now we are focusing on semantics rather than syntax, but we'll keep this issue open.

[ianlancetaylor]

Upon discussion with Go 2 proposal review committee, we would like to fold this issue into the general generics issue #15292. Please also feel free to add a link to this issue to https://github.com/golang/go/wiki/Go2GenericsFeedback. We don't think it will be helpful to keep multiple generics syntax issues open simultaneously, spreading the discussion to too many different places.

-- for @golang/proposal-review