Member walks silently drop unrecognized declarations (nested types, typealiases, indexed subscripts)
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 74/100
Research direction
Start in Interpreter+Structs.swift, then inspect the shared member walks for classes, enums, and extensions. Compare their known declaration branches with the rejectMacroMember pattern from #14 and run the nested-type and indexed-subscript reproductions. Done means every currently unsupported member declaration fails at its declaration with an honest RuntimeError rather than disappearing silently.
Written by the indexing model from the issue text.
Description
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,actorinside a type) typealiasmembers- indexed subscripts — the
subscriptDeclbranch keeps only thesubscript(dynamicMember:)shape and silently ignoressubscript(_ i: Int)(declaring one succeeds; using it then fails confusingly) protocoldeclarations 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.
- Dominant language
- Swift
- Stars
- 75
- Forks
- 6
- Avg merge
- 25m
- Merged PRs (30d)
- 1
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Cocoanetics/SwiftScript
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Cocoanetics/SwiftScript#22 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Cocoanetics/SwiftScript#20 ·
All issues in Cocoanetics/SwiftScript
Similar issues
-
good first issue help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
harf-promo/decaffeinate#21 ·
-
enhancement low-priority milestone-qa tests
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
lognorman20/monaco#4877 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
enhancement P3 Starter Task users requested
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day