Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go2go: another parsing ambiguity #39654

Closed
benjaminjkraft opened this issue Jun 17, 2020 · 3 comments
Closed

cmd/go2go: another parsing ambiguity #39654

benjaminjkraft opened this issue Jun 17, 2020 · 3 comments
Assignees
Milestone

Comments

@benjaminjkraft
Copy link

@benjaminjkraft benjaminjkraft commented Jun 17, 2020

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 andybons added this to the Unplanned milestone Jun 17, 2020
@andybons
Copy link
Member

@andybons andybons commented Jun 17, 2020

@benjaminjkraft
Copy link
Author

@benjaminjkraft benjaminjkraft commented Jun 17, 2020

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
Copy link
Contributor

@griesemer griesemer commented Jun 17, 2020

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.

@griesemer griesemer closed this Jun 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.