Skip to content

Member walks silently drop unrecognized declarations (nested types, typealiases, indexed subscripts) #18

Description

@odrobnik

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions