It works without the parentheses, but i agree it is somewhat inconsistent.

Related, #51655. I am not sure if there is anything to fix here, seems to me that the compiler is behaving according to the spec, no?

Note that this isn't quite the same as #51655, which is about embedding a type in a struct, not an interface. Embedding a type in a struct definitely does not permit parentheses.

But I'm not clear on why embedding a type in an interface doesn't permit parentheses. The current syntax says that an interface type can be a TypeElem which can be a TypeTerm which can be a Type which can be a "(" Type ")". So it seems to me that it should be permitted in this case.

CC @griesemer

Note that in 1.17 it's also not permitted to parenthesize an embedded interface (1.17 spec):

package p

type T0 interface{}

type T1 interface{
	(T0)
}

leads to:

x.go:6:2: syntax error: cannot parenthesize embedded type

so the behavior is simply in keeping with the existing pre-1.18 spec. At some point in the exploration of generics syntax we permitted parentheses everywhere (interfaces and structs) but eventually we went back to the more minimal changes to the syntax. #51655 is because we didn't fully revert the changes in go/parser.

I don't see any particular reason for not permitting parentheses here, but the code as is is intentional, not a bug.

Does this mean the current 1.18 syntax spec is not correct?

@beoran Fair point - the spec's syntax here clearly does permit parentheses as @ianlancetaylor already observed. Agreed, this is a bug (presumably in the parser).

@griesemer Actually, I meant to say that this might be a bug in the spec. But if you say it is a bug in the compiler, then I will defer to your judgement. However, perhaps it would be good to see how gccgo reacts to this code?

gccgo does not yet support generics. I'm working on it.

Change https://go.dev/cl/400797 mentions this issue: cmd/compile/internal/types2: permit parentheses around types in interfaces

@beoran If the existing behavior is considered correct, then the spec is wrong. If the spec is correct, then the existing behavior is incorrect. Since it's permitted to write things like ~(chan<- int), we should also allow (chan<- int) for consistency. The spec already says so, it's more consistent, and adjusting the parser makes it simpler. So it seems like a win-win all around. CL pending.

@griesemer well yes, it is either the spec or the go compiler that is wrong. I was just wondering which of the two it was. But you are right, in this case it is more consistent to say that the compiler is wrong.

Thanks for the fix. I like how this actually makes the go compiler 's parser simpler.