Found while implementing #14. The struct / class / enum / extension member walks match the declaration kinds they know (var, init, func, subscript(dynamicMember:)) with an if / else-if chain that has no final else — every other member declaration is dropped without a sound, and the failure surfaces later as a misleading downstream error.
Reproduction (current main):
struct Outer {
struct Inner { var x: Int }
typealias ID = Int
}
let i = Outer.Inner(x: 1)
print(i.x)
error: type 'Outer' has no member 'Inner'
The declaration loaded fine — the nested struct Inner and the typealias ID were both silently discarded — and the error the user gets points at the use site with a claim that contradicts the source they can see. That is exactly the plausible-wrong-behavior class the issue #8 work (loud divergences) and the attribute preflight exist to prevent: a boundary error at the declaration would say "the interpreter can't do this yet"; the current error says "your code is wrong" when it isn't.
Silently dropped today (verified against the walk in Interpreter+Structs.swift; the class/enum/extension walks share the shape):
- nested type declarations (
struct, class, enum, actor inside a type)
typealias members
- indexed subscripts — the
subscriptDecl branch keeps only the subscript(dynamicMember:) shape and silently ignores subscript(_ i: Int) (declaring one succeeds; using it then fails confusingly)
protocol declarations nested in a type
Freestanding macros in member position (struct S { #foo(\"x\") }) were on this list too; the #14 PR makes that one loud (rejectMacroMember), and its pattern is the suggested fix here: keep the walks' known branches, add a final else that throws RuntimeError.unsupported("declaration \(decl.syntaxNodeType) in member position", at: …) so unhandled member kinds fail at the declaration with an honest boundary message. Nested-type support can then be added later, kind by kind, without users ever passing through the misleading state.
Found while implementing #14. The struct / class / enum / extension member walks match the declaration kinds they know (
var,init,func,subscript(dynamicMember:)) with anif / else-ifchain that has no finalelse— every other member declaration is dropped without a sound, and the failure surfaces later as a misleading downstream error.Reproduction (current
main):The declaration loaded fine — the nested
struct Innerand thetypealias IDwere both silently discarded — and the error the user gets points at the use site with a claim that contradicts the source they can see. That is exactly the plausible-wrong-behavior class the issue #8 work (loud divergences) and the attribute preflight exist to prevent: a boundary error at the declaration would say "the interpreter can't do this yet"; the current error says "your code is wrong" when it isn't.Silently dropped today (verified against the walk in
Interpreter+Structs.swift; the class/enum/extension walks share the shape):struct,class,enum,actorinside a type)typealiasmemberssubscriptDeclbranch keeps only thesubscript(dynamicMember:)shape and silently ignoressubscript(_ i: Int)(declaring one succeeds; using it then fails confusingly)protocoldeclarations nested in a typeFreestanding macros in member position (
struct S { #foo(\"x\") }) were on this list too; the #14 PR makes that one loud (rejectMacroMember), and its pattern is the suggested fix here: keep the walks' known branches, add a finalelsethat throwsRuntimeError.unsupported("declaration \(decl.syntaxNodeType) in member position", at: …)so unhandled member kinds fail at the declaration with an honest boundary message. Nested-type support can then be added later, kind by kind, without users ever passing through the misleading state.