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.) On Sunday, June 28, 2020 at 6:29:08 PM UTC-4, Ian Lance Taylor wrote: > > On Sun, Jun 28, 2020 at 2:56 PM <zhouhai...@gmail.com <javascript:>> > wrote: > > > > 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? > > 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 > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/d8a6436f-6f0c-441c-8888-f060b714cb6do%40googlegroups.com.
