On Tue, Jun 16, 2020 at 4:49 PM Ben Kraft <benjaminjkr...@gmail.com> wrote:
>
> 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.
>
> 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.
Interesting case. At the very least we need to describe this case in
the design draft. Maybe there is a way that we can fix it.
Please do open a bug report for this. 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/CAOyqgcUqez0LzFbSuYcGa5T4ZUhnhAO6jhSrdMfohGw4K6bSzQ%40mail.gmail.com.
