[edited]
PS: This bug was introduced exposed with a80c5f0 .

This is a general cycle detection bug. Replacing interface with struct:

package p

type A struct {
	f func() B
	b B
}

type B struct {
	A
}

type-checks but it shouldn't.

Root cause:

Analysis of detailed design proposal (Jul-Sep 2019) is not based on formal model.

@av86743 Thanks, but the design proposal you're mentioning is not the root cause at all - it is in fact unrelated. It just so happens that I changed the implementation of interface type-checking entirely when implementing overlapping interfaces, which in turn exposed an underlying bug. As I have mentioned here, this bug also appears for structs which have nothing to do with interfaces; in fact this bug has been around for an embarrassingly long time.

@griesemer

... the design proposal you're mentioning is not the root cause at all ...

This is not what I said. I said that "Analysis of ... proposal is [essentially absent]".

... in fact this bug has been around for an embarrassingly long time.

I certainly appreciate your recognition of the fact.

@av86743 Hm, apologies for the misunderstanding, but I don't understand what you are saying. Since the specific proposal is unrelated to this bug, I don't see why you bring in that proposal in the first place.

@griesemer

... I don't see why you bring in that proposal in the first place.

This proposal is the first and only place where you specify (in section "Proposal") what you are intending to do. It also indicates a period when implementation has taken place.

@av86743 Please see the updated title of this issue. It is unrelated to the proposal.

@griesemer

Your example with structs does not type-check with current go1.12 (and likely with earlier go versions) - as it should. It started to fail only after "unrelated" changes per said proposal. Think a moment about it.

@av86743 The latest released version is go1.13 (commit cc8838d), and on my machine the struct example is (incorrectly) accepted. This code failed before said proposal was proposed or implemented.

@griesemer

[edited]
PS: This bug was introduced exposed with a80c5f0 .

Then what about this?

@av86743 Initial guess/misdiagnosis - which is why I corrected it once I realized that this was unrelated. The problem is due to how cycle detection was changed a while back. Anyway, I consider this discussed resolved at this point. Thanks.

"... bug was exposed with [commit]" is rather strange choice of wording if you admit that regression in cycle detection appeared before commit was applied (or even existed.) Clearly, the initial interface example is not part of the commit in question but was somehow arrived at, at a later time. Which in turn translates into "... bug was not exposed with [commit]". Hence the root cause.

Change https://golang.org/cl/196338 mentions this issue: go/types: fix cycle detection