cmd/go2go: another parsing ambiguity

[benjaminjkraft]

Consider the following code (playground):

type R(type T) struct{}
func F(type T)() {
     _ = func() R(T) { return R(T){} }
}

That is, we have some parameterized type R(T), and a function literal which returns that type R(T). (This is simplified from an example I found while writing generic composition with a result type.)

This currently fails with the following error message: prog.go:5:23: expected operand, found 'return' (the referenced location is indeed the return). (As an aside, this error message was pretty opaque -- not sure if improving that sort of thing is in-scope for the prototype.)

The issue appears to be a parsing ambiguity similar to the one described in the design draft, where func() R(T) has been interpreted as (func() R)(T). But the solution described there doesn't work: writing func() (R(T)) gets parsed as (and gofmted to) func() (R T). That is, it runs into another parsing ambiguity described in the draft. As a further workaround, I eventually realized to use func() (_ R(T)); from there things work fine.

Presumably the solution to the second parsing ambiguity could also work here, if applied to function returns; of course that expands the compatibility break described there. Or, this could be documented similar to [](R(T)).

See also golang-nuts thread.

[andybons]

@griesemer @ianlancetaylor

[benjaminjkraft]

To be clear, the workaround in full looks like:

type R(type T) struct{}
func F(type T)() {
	_ = func() (_ R(T)) { return R(T){} }
}

[griesemer]

There's only one issue here, which is the ambiguity of instantiated (result) parameter types. As you say, this works.

In short, this is working as expected at the moment. I am going to close this as not a bug; but we are looking into changing the parsing here. This is obviously a very common issue for lots of people.