go/types: accepts invalid type T = interface{ f(T) }

[griesemer]

cmd/compile rejects it as an invalid recursive type declaration; go/types accepts it (but T is an invalid type). Should it be valid?

[griesemer]

cc @jimmyfrasche

[bcmills]

If that is valid, then it seems like mutually-recursive aliases should be valid too.
(Consider https://play.golang.org/p/osIdGepuAc vs. https://play.golang.org/p/vs5gMnTe7P.)

Mutually-recursive aliases would address the problem I described in #8082 (comment).

[jimmyfrasche]

@griesemer

If this were valid, would it makes sense for

type LL = struct {
  next *LL
}

to be valid as well?

[griesemer]

@jimmyfrasche Indeed. It appears that go/types correctly types this unnamed linked list type, but there's an issue with interfaces.

[ianlancetaylor]

gccgo also rejects this:

foo.go:3:6: error: invalid recursive alias ‘T’
 type T = interface{ f(T) }
      ^

The type alias proposal at https://github.com/golang/proposal/blob/master/design/18130-type-alias.md seems fairly clear that this is invalid.

[jimmyfrasche]

Specifically https://github.com/golang/proposal/blob/master/design/18130-type-alias.md#type-cycles

Of those type T = *T is the only one that is objectively wrong.

The examples here could be given sensible meaning, though it wouldn't be possible to write out the equivalent literal type because infinity.

This came up in the context of #8082 which would require similar machinery to support self-referential interface definitions.

[bcmills]

Of those type T = *T is the only one that is objectively wrong.

That one isn't obviously wrong either. The analogous declaration works with defined types: https://play.golang.org/p/ID9xg3BBtT

[jimmyfrasche]

@bcmills it feels different than the case for defined types in some fundamental way but attempting to articulate why fails me in a way that makes me suspect that you're right. However, if later someone proves it wrong I reserve the right to say, "Aha!" :).

[bcmills]

The justification given in the alias doc for prohibiting recursive aliases is that ‘aliases must be possible to “expand out”’.

Allowing recursive interfaces would mean that there exist type aliases for which there is no equivalent, finite non-alias type literal. I'm ok with that, but it's certainly not a trivial property: it would mean, for example, that a function that prints out a Go type by traversing it recursively would have to break that recursion somehow.

[gopherbot]

Change https://golang.org/cl/115455 mentions this issue: go/types: use color-marking based cycle detection at package level