<div dir="ltr">Hi Dave,<div><br></div><div>(inline)</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 19, 2016 at 10:46 AM, Dave Abrahams <span dir="ltr">&lt;<a href="mailto:dabrahams@apple.com" target="_blank">dabrahams@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br></span><span class="">(snip)<br>
&gt;<br>
&gt; Agreed, I think we can easily do it internally for the use cases that<br>
&gt; are most important (collections, certain built-in types), etc. It&#39;s<br>
&gt; probably out-of-scope for the PR I have out right now<br>
&gt; (<a href="https://bugs.swift.org/browse/SR-88" rel="noreferrer" target="_blank">https://bugs.swift.org/browse/SR-88</a><br>
</span>&gt; &lt;<a href="https://bugs.swift.org/browse/SR-88" rel="noreferrer" target="_blank">https://bugs.swift.org/browse/SR-88</a>&gt;), but maybe I can sketch an<br>
<span class="">&gt; implementation and we can discuss further on swift-dev. (Since it&#39;s<br>
&gt; all internal changes and no public-facing API changes the entire<br>
&gt; swift-evolution process probably isn&#39;t necessary.) LMK if you think<br>
&gt; that&#39;s the best way to proceed.<br>
<br>
</span>It sounds like a fine plan.  You&#39;d have to land it before SR-88 to<br>
keep the tests working, right?<br></blockquote><div><br></div><div>The PR for SR-88 actually has changes to all the tests to keep them passing without doing any additional work. If I did do the work described above (to prettify the common use cases), I&#39;d just remove those test changes and keep the tests the way they look right now. </div><div><br></div><div>This means I can either:</div><div><br></div><div>1. Land the PR now, and then make the prettifying changes + revert the tests and commit that as another PR</div><div>2. Add the prettifying changes as part of the current PR and delete the changes I made to the tests (this will make the PR a lot smaller overall; many of the changes to the test files will disappear)</div><div><br></div><div>Let me know if that makes sense.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; - Certain types like CGRect don&#39;t conform to CustomStringConvertible,<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; CustomDebugStringConvertible, Streamable, etc. Having a custom summary for<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; these types customized by the corresponding Mirror would allow for a<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; &#39;pretty&#39; representation during reflection in lieu of the ugly one generated<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; by the runtime without making more substantial changes to the API which<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; might break third-party code (such as conforming CGRect to any of the<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; aforementioned protocols).<br>
&gt;&gt;<br>
&gt;&gt; I don&#39;t think it&#39;s worth worrying about breakage from adding a<br>
&gt;&gt; CustomDebugStringConvertible conformance to CGRect.<br>
&gt;<br>
&gt; Okay, that makes sense. Since it&#39;s a public-facing API change, though,<br>
&gt; I should bring it up on the evolution list and write a proposal. I can<br>
&gt; do that tonight if that&#39;s the most sensible way forward.<br>
<br>
</span>Sorry, I don&#39;t mean to be dense, but what API change are you talking<br>
about making?<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>No worries. The specific API change I was talking about was adding CustomDebugStringConvertible conformance to CGRect (and, for completeness, CGSize and CGPoint). If that doesn&#39;t count as a public-facing API change I&#39;ll just add it into my PR tonight.</div><div><br></div><div>Best,</div><div>Austin</div></div></div></div>