<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="">Hi Dave,<div class=""><br class=""></div><div class="">Thanks for the insight, I think we're on the same page overall. Responses inline.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 18, 2016, at 9:56 AM, Dave Abrahams 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 class=""><br class="">Hi Austin, I think we should discuss it here.<br class=""><br class="">First off, dump() was really just added as a proof-of-concept by Joe<br class="">Groff when he implemented the original mirror system. We decided to<br class="">keep it around because it seemed like it might be useful for somebody,<br class="">but one possibility to consider is that it should be retired.<br class=""><br class=""></div></div></blockquote><div><br class=""></div><div>Regarding 'dump()', if it was intended 'just' a proof of concept I agree with you - it makes sense to consider retirement. Perhaps designing a replacement (if one should exist at all) should be considered alongside the larger overhaul of the reflection system covered in SR-88. It is used quite extensively in the test suite as a way to quickly validate the structure of instances under test, so removing it would require refactoring many of the unit tests.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">For the rest, see below<br class=""><br class="">on Mon Jan 18 2016, Austin Zheng via swift-evolution <<a href="http://swift-evolution-m3fhrko0vlzytjvyw6ydsg-at-public.gmane.org" class="">swift-evolution-m3FHrko0VLzYtjvyW6yDsg-AT-public.gmane.org</a>> wrote:<br class=""><br class=""></div></div></blockquote><div><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">I would like to suggest that there might be a purpose for "summary":<br class=""><br class="">- Types with children, especially container types like arrays, often<br class="">print out a description of their children as part of their debugDescription<br class="">or description, redundant when using an API like dump() which provides a<br class="">structural representation of the children of the subject. In such cases a<br class="">lighter-weight description (like "3 elements") might be more appropriate to<br class="">represent to the user.</blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite" class=""><br class=""></blockquote></div><blockquote type="cite" class=""><div class=""><div class="">Agreed, if we keep dump, we ought to recover that functionality somehow.<br class="">However, IMO we might be best off synthesizing that text for mirrors<br class="">with children by using their DisplayStyle and/or checking their<br class="">conformances. It doesn't seem to be worth expanding the protocols for.<br class=""></div></div></blockquote><div><br class=""></div><div>Agreed, I think we can easily do it internally for the use cases that are most important (collections, certain built-in types), etc. It's probably out-of-scope for the PR I have out right now (<a href="https://bugs.swift.org/browse/SR-88" class="">https://bugs.swift.org/browse/SR-88</a>), but maybe I can sketch an implementation and we can discuss further on swift-dev. (Since it's all internal changes and no public-facing API changes the entire swift-evolution process probably isn't necessary.) LMK if you think that's the best way to proceed.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">- Certain types like CGRect don't conform to CustomStringConvertible,<br class="">CustomDebugStringConvertible, Streamable, etc. Having a custom summary for<br class="">these types customized by the corresponding Mirror would allow for a<br class="">'pretty' representation during reflection in lieu of the ugly one generated<br class="">by the runtime without making more substantial changes to the API which<br class="">might break third-party code (such as conforming CGRect to any of the<br class="">aforementioned protocols).<br class=""></blockquote></blockquote></blockquote></blockquote></blockquote><br class="">I don't think it's worth worrying about breakage from adding a<br class="">CustomDebugStringConvertible conformance to CGRect.<br class=""></div></div></blockquote><div><br class=""></div><div>Okay, that makes sense. Since it's a public-facing API change, though, I should bring it up on the evolution list and write a proposal. I can do that tonight if that's the most sensible way forward.</div><div><br class=""></div><div>Best,</div><div>Austin</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">I know that Mirror (and reflection as a whole) are being considered for<br class="">major design changes, so this would be a minor transient change to make the<br class="">API easier to work with in the meantime.<br class=""><br class="">Please let me know whether or not you think this proposed change is<br class="">meaningful and worthwhile, or if you have any questions.<br class=""><br class="">Best,<br class="">Austin<br class=""></blockquote></blockquote></blockquote><br class="">Hey, Austin,<br class=""><br class="">Is this still something we need to discuss, or did it get resolved<br class="">somehow?<br class=""><br class="">Thanks,<br class="">Dave<br class=""></blockquote></blockquote><br class="">Thanks,<br class="">Dave<br class=""><br 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></div></blockquote></div><br class=""></div></body></html>