Consider the following code (playground
<https://go2goplay.golang.org/p/ShKAj7ihGqk>):
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
<https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#instantiating-types-in-type-literals>,
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
<https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#using-generic-types-as-unnamed-function-parameter-types>.
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.
Not sure if this qualifies as discussion or a bug report; I figured I'd
start here but happy to make an issue if that's preferred.
--
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/2575e57e-d79c-494a-b4b0-9a773171f1c2n%40googlegroups.com.
