<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"><<a href="mailto:dabrahams@apple.com" target="_blank">dabrahams@apple.com</a>></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>
><br>
> Agreed, I think we can easily do it internally for the use cases that<br>
> are most important (collections, certain built-in types), etc. It's<br>
> probably out-of-scope for the PR I have out right now<br>
> (<a href="https://bugs.swift.org/browse/SR-88" rel="noreferrer" target="_blank">https://bugs.swift.org/browse/SR-88</a><br>
</span>> <<a href="https://bugs.swift.org/browse/SR-88" rel="noreferrer" target="_blank">https://bugs.swift.org/browse/SR-88</a>>), but maybe I can sketch an<br>
<span class="">> implementation and we can discuss further on swift-dev. (Since it's<br>
> all internal changes and no public-facing API changes the entire<br>
> swift-evolution process probably isn't necessary.) LMK if you think<br>
> that's the best way to proceed.<br>
<br>
</span>It sounds like a fine plan. You'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'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>
>>>>>>> - Certain types like CGRect don't conform to CustomStringConvertible,<br>
>>>>>>> CustomDebugStringConvertible, Streamable, etc. Having a custom summary for<br>
>>>>>>> these types customized by the corresponding Mirror would allow for a<br>
>>>>>>> 'pretty' representation during reflection in lieu of the ugly one generated<br>
>>>>>>> by the runtime without making more substantial changes to the API which<br>
>>>>>>> might break third-party code (such as conforming CGRect to any of the<br>
>>>>>>> aforementioned protocols).<br>
>><br>
>> I don't think it's worth worrying about breakage from adding a<br>
>> CustomDebugStringConvertible conformance to CGRect.<br>
><br>
> Okay, that makes sense. Since it's a public-facing API change, though,<br>
> I should bring it up on the evolution list and write a proposal. I can<br>
> do that tonight if that's the most sensible way forward.<br>
<br>
</span>Sorry, I don'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't count as a public-facing API change I'll just add it into my PR tonight.</div><div><br></div><div>Best,</div><div>Austin</div></div></div></div>