The error message is "cannot convert nil to type F" but F is clearly a function and thus nil can be converted into that function (of whatever type). The problem here is the type cycle; the conversion looks at a type that is not yet fully set up.
This example is primarily interesting as a test case.
The text was updated successfully, but these errors were encountered:
@cznic I'm fairly sure it's not on purpose that it works. There's a reason why the compiler complains; we go through great lengths to detect such cycles, even if they are "obviously" not cyclic to a human reader.
The type in question has a computable size only because we know it's a function, but the function may not be set up yet (not even partially) as we are in the definition of that very function. It's non-trivial to get right which is why go/types and the compilers have various cycle-related issues, mostly esoteric and not relevant for real code (otherwise they would have shown up a long time ago).
But let's not discuss this here. It would be a very long discussion. The reason I am collecting these is in order to come up with a model of what we "should" accept and what we can safely refuse (even if a human reader could determine a type). Notably the spec remains silent on the subject exactly because it's tricky to specify.