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
spec: Document rules for recursive type and other self-referential decls #5069
Comments
This applies also to named fields for structs, and arrays, too. In general, all "composite value types" cannot contain themselves directly or indirectly unless there's a reference type between. It's somewhat obvious but it probably should be spec'ed out explicitly, after all it's something that typecheckers go though some length to check. Labels changed: added documentation. Owner changed to @griesemer. Status changed to Accepted. |
Any update on this issue? As a Go trainer, I'd like to be able to point participants to an authoritative passage of the spec that would elucidate the restriction. |
No, this has not been addressed yet, sorry. But the rules are fairly simple:
There's a rule of thumb for 1): For example, given: type S struct {
a S
} there is no way to write down a composite literal for var s = S{a: S{a: S{a: ... // never ends (and note that you're not allowed to use a variable of type S inside the composite literal to "shortcut": This may be a reasonable and intuitive way to teach this restrictions to new Go programmers. It's also accurately reflecting the reason for the restriction (the type checker does exactly this test). |
@griesemer This issue is in the 1.18 milestone; time to move to 1.19? |
Yes. This will be hard (and thus take time) to document sufficiently precisely without being too prescriptive. Moving to 1.19. |
The text was updated successfully, but these errors were encountered: