<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I believe 'summary' is obsolete, and you're supposed to use Custom[Debug]StringConvertible to customize your type's reporting now.<div class=""><br class=""></div><div class="">-Joe</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 29, 2015, at 10:38 PM, Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi all,<div class=""><br class=""></div><div class="">I'd like to gauge reaction for a proposal I was considering: adding to the standard library's Mirror type a 'summary' 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 class=""><br class=""></div><div class="">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's types off the _Reflectable API and have them use the CustomReflectable API, and changing dump() accordingly.</div><div class=""><br class=""></div><div class="">The extant implementation of dump() uses a property on _MirrorType called "summary". (This is where e.g. "4 elements" comes from when you dump() an array.) "summary" 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 class=""><br class=""></div><div class="">I would like to suggest that there might be a purpose for "summary":</div><div class=""><br class=""></div><div class="">- 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 "3 elements") might be more appropriate to represent to the user.</div><div class=""><br class=""></div><div class="">- Certain types like CGRect don't conform to CustomStringConvertible, CustomDebugStringConvertible, Streamable, etc. Having a custom summary for these types customized by the corresponding Mirror would allow for a 'pretty' 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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Please let me know whether or not you think this proposed change is meaningful and worthwhile, or if you have any questions.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Austin</div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=RoDF4MveSEMYBIqIJA6ub1g8cOZ-2BVYvqV-2FqygPhjPn9QSfLonyCZl-2BHuC4mjrTgtUo5RzgLB9UXxR-2ForNODpFEpVzHt7-2Fr8kYPe7xWw0WSRm0iPZ-2FKGcvwn2wKbxFgPOLk6-2BfoqiB97R0O-2ByNupoHk6T-2FHRE2d2LcvD5bDdvVEFBNBYWKmQWpV2K-2FhigeugT4HH-2FlnbfPOh-2BL0CY4fhsopB3LNCmozFpoBBNAeZm-2FOY-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>