<div dir="ltr">Hi all,<div><br></div><div>I&#39;d like to gauge reaction for a proposal I was considering: adding to the standard library&#39;s Mirror type a &#39;summary&#39; property, and the option to initialize a Mirror with a custom summary. If no custom summary is provided, the summary would default to the string produced by calling String(reflecting: subject) on the subject at the time of mirror creation.</div><div><br></div><div>Some context: right now, there are two APIs for mirrors in the standard library: CustomReflectable, which is publicly exposed and relies on the conforming type creating a Mirror object, and _Reflectable, which relies on the conforming type having a companion type conforming to _MirrorType. A short-term goal is to migrate the standard library&#39;s types off the _Reflectable API and have them use the CustomReflectable API, and changing dump() accordingly.</div><div><br></div><div>The extant implementation of dump() uses a property on _MirrorType called &quot;summary&quot;. (This is where e.g. &quot;4 elements&quot; comes from when you dump() an array.) &quot;summary&quot; is absent from Mirror or any types related to CustomReflectable. I asked Joe Groff about this and the rationale was that it was deemed too similar to debugDescription (or String(reflecting: foo)) to be worth carrying over.</div><div><br></div><div>I would like to suggest that there might be a purpose for &quot;summary&quot;:</div><div><br></div><div>- Types with children, especially container types like arrays, often print out a description of their children as part of their debugDescription or description, redundant when using an API like dump() which provides a structural representation of the children of the subject. In such cases a lighter-weight description (like &quot;3 elements&quot;) might be more appropriate to represent to the user.</div><div><br></div><div>- Certain types like CGRect don&#39;t conform to CustomStringConvertible, CustomDebugStringConvertible, Streamable, etc. Having a custom summary for these types customized by the corresponding Mirror would allow for a &#39;pretty&#39; representation during reflection in lieu of the ugly one generated by the runtime without making more substantial changes to the API which might break third-party code (such as conforming CGRect to any of the aforementioned protocols).</div><div><br></div><div>I know that Mirror (and reflection as a whole) are being considered for major design changes, so this would be a minor transient change to make the API easier to work with in the meantime.</div><div><br></div><div>Please let me know whether or not you think this proposed change is meaningful and worthwhile, or if you have any questions.</div><div><br></div><div>Best,</div><div>Austin</div></div>