Summary
Recursive descriptions can fail for field types that require an additional derived specialization before description lookup. The observed SwiftUI.EventID case appears to be caused by missing Optional<EventID> specialization, not just by recursive rendering skipping the nominal type.
Reproduction
- Open RuntimeViewer and inspect SwiftUI/SwiftUICore.
- Open
SwiftUI.EventListenerPhase<SwiftUI.MouseEvent>.
- Look at fields that reference
SwiftUI.EventID, for example:
var events: AttributeGraph.Attribute<[SwiftUI.EventID : SwiftUI.EventType]>
var trackingID: SwiftUI.EventID?
- Compare these fields with nearby fields whose underlying descriptions/layout details are recursively expanded.
Actual Behavior
Some field types remain displayed as plain referenced types because RuntimeViewer cannot find their specialized recursive description. In the observed case, trackingID: SwiftUI.EventID? likely needs an Optional<SwiftUI.EventID> specialization before recursive description lookup can succeed.
A similar symptom appears for phase-like generic types. If GesturePhase<Event> or another phase type does not have recursiveDescription, but Event has already been specialized, RuntimeViewer still needs to recursively specialize the dependent generic phase type before generating its description.
Expected Behavior
Before generating recursive descriptions, RuntimeViewer should recursively derive and register the specializations needed by the referenced field type.
Expected examples:
- For
T?, the specialization path should have a fast entry for Optional<T>, conceptually Optional + the current specialized type.
- For dependent generic wrappers such as
GesturePhase<Event>, once Event is specialized, RuntimeViewer should proactively specialize the wrapper chain and then generate/lookup the recursive description.
Notes / Possible Fix Direction
This likely belongs in the specialization chain rather than only in the description renderer:
- Add an
Optional fast path that synthesizes Optional<CurrentType> specialization when a field references CurrentType?.
- Recursively specialize wrapper/generic field types before generating recursive descriptions.
- Generate the description only after those derived specializations are available, so lookup can find the expanded type description.
Summary
Recursive descriptions can fail for field types that require an additional derived specialization before description lookup. The observed
SwiftUI.EventIDcase appears to be caused by missingOptional<EventID>specialization, not just by recursive rendering skipping the nominal type.Reproduction
SwiftUI.EventListenerPhase<SwiftUI.MouseEvent>.SwiftUI.EventID, for example:var events: AttributeGraph.Attribute<[SwiftUI.EventID : SwiftUI.EventType]>var trackingID: SwiftUI.EventID?Actual Behavior
Some field types remain displayed as plain referenced types because RuntimeViewer cannot find their specialized recursive description. In the observed case,
trackingID: SwiftUI.EventID?likely needs anOptional<SwiftUI.EventID>specialization before recursive description lookup can succeed.A similar symptom appears for phase-like generic types. If
GesturePhase<Event>or another phase type does not haverecursiveDescription, butEventhas already been specialized, RuntimeViewer still needs to recursively specialize the dependent generic phase type before generating its description.Expected Behavior
Before generating recursive descriptions, RuntimeViewer should recursively derive and register the specializations needed by the referenced field type.
Expected examples:
T?, the specialization path should have a fast entry forOptional<T>, conceptuallyOptional+ the current specialized type.GesturePhase<Event>, onceEventis specialized, RuntimeViewer should proactively specialize the wrapper chain and then generate/lookup the recursive description.Notes / Possible Fix Direction
This likely belongs in the specialization chain rather than only in the description renderer:
Optionalfast path that synthesizesOptional<CurrentType>specialization when a field referencesCurrentType?.