[swift-evolution] Custom summary for Mirrors?

[Austin Zheng]

Hi Dave,

(inline)

On Tue, Jan 19, 2016 at 10:46 AM, Dave Abrahams <dabrahams at apple.com> wrote:

>
> (snip)
> >
> > 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
> > (https://bugs.swift.org/browse/SR-88
> > <https://bugs.swift.org/browse/SR-88>), 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.
>
> It sounds like a fine plan.  You'd have to land it before SR-88 to
> keep the tests working, right?
>

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.

This means I can either:

1. Land the PR now, and then make the prettifying changes + revert the
tests and commit that as another PR
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)

Let me know if that makes sense.


>
> >>>>>>> - 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).
> >>
> >> I don't think it's worth worrying about breakage from adding a
> >> CustomDebugStringConvertible conformance to CGRect.
> >
> > 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.
>
> Sorry, I don't mean to be dense, but what API change are you talking
> about making?
>
>
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.

Best,
Austin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160119/4a18bdf0/attachment.html>