[generic] Readibility of Multiple Parenthsis

[zhouhai...@gmail.com]

Hi,

After looking at the latest proposal - https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md, and also checked a curated list of discussion at - https://groups.google.com/forum/#!msg/golang-nuts/uQDrcHDwT_w/Y-Myzuw_AQAJ.

However, I do find myself still interested in a case like below:

type foo struct{}

func bar(x int) func(int) int {
    return func(y int) int {
        return x + y
    }
}

func main() {
    foo := 1
    result := bar(foo)(2)
    fmt.Println(result)
}

I believe a function which returns another function in current Go world is pretty normal. I specifically mocked an example above - where the first parameter name appears to collide with a type name.

With that said, I guess compiler won't have any issues to figure it out when it is type parameter and when it is not. However, I think that's not trivial for a human, though.

So is this a problem or I may just have ignored anything?

Thanks,

Haibing

[Ian Lance Taylor]

There are many ways to write ambiguous code in Go, or in any
programming language. The interesting question here is not "can it be
ambiguous?" It is "will it be ambiguous in practice?" That is why I
am encouraging people to write real code using the design draft, so
that we can see how that real code looks.

In particular, the ambiguity in your example hinges on a collision
between a variable name and a type name. In Go, for better or for
worse, variable names and type names live in the same namespace and
can shadow each other. Yet people are rarely confused by this in
practice. Real code rarely uses identifiers like "foo". In real
code, when we look at an identifier, how often are we confused as to
whether that identifier is a variable, a function, a type, or a
constant? And how often do those confusing cases collide with a case
like a function that returns a function that is immediately called?

I can guess answers to those questions, but I don't know. The only
way to know is to look at real code.

Thanks.

Ian

[Jake Montgomery]

I understand Ian's position of wait and see. But for completeness, I will point out that this new 'ambiguity' is different from the current cases where there would be a "collision

between a variable name and a type name." As far as I can tell, any such collision in Go 1 would fail to compile. However, with the current parentheses based generics, such collisions could end up compiling, or failing to compile at a later location in a confusing way:

https://go2goplay.golang.org/p/nufvRIolhmF

package main

import "fmt"

type foo int

type Intish interface {
    type int
}

func bar(type T Intish)(x T) func(T) T {
    return func(y T) T {
        return x + y
    }
}

func one() {

    foo := 1
    result := bar(foo)(2)

    fmt.Printf("%T\n", result)
}

func two() {
    result := bar(foo)(2)
    fmt.Printf("%T\n", result)
}

func main() {
    one()
    two()
}

Output:

int
func(main.foo) main.foo

The first set a parens after bar can reasonably be either a type or a value. Whether this will actually lead to confuision or not only experince will tell (as Ian keeps saying.)

(OT, but I am one of those folks who is suffering from parenthesis fatigue, and wish there were some more clear way to denote a type when using a generic.)

[Steven Blenkinsop]

On Sun, Jul 5, 2020 at 12:22 PM, Jake Montgomery <jake...@gmail.com> wrote:

I understand Ian's position of wait and see. But for completeness, I will point out that this new 'ambiguity' is different from the current cases where there would be a "collision

between a variable name and a type name." As far as I can tell, any such collision in Go 1 would fail to compile. However, with the current parentheses based generics, such collisions could end up compiling, or failing to compile at a later location in a confusing way:

In an expression x(y)(z), x could be already be a type or a value and successfully compile only to have unexpected results later on if there was any confusion about what x refers to. What's changing is that y could also now be a type or a value.

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

Ultimately, these kinds of examples are contrived. They're relying on shadowing unexported identifiers with meaningless names in your own code, and using the same name for a type vs. a value.