Well, in my experience performance issues tend to come not from trying to display a single object, but when you have an aggregation of many objects. For example, displaying one Int is pretty lightweight, as is an [Int] with a handful of elements, but displaying an [Int] with million elements is not (this is assuming that collections will run the playgroundRepresentation on their individual elements as they do currently). I don’t think the current proposal can solve this issue as it’s pitched currently. (For those curious, this doesn’t have a good solution today, either: the best “solution” I’ve been able to come up with is to move performance-sensitive out into a Playground’s Sources folder, which isn’t displayed.)
Fundamentally, I don’t think it’s clear what the “default” value is supposed to be: we already have three different interpretations of what it could do: do literally nothing (i.e. display an empty representation), use a superclass’s representation, or use a structural representation based on whether the type is an enum, struct, class, etc. I think we need to clear up what the default actually means (and if we even need it at all) before we can proceed. Saagar Jha > On Jan 10, 2018, at 10:02, Chris Lattner <clatt...@nondot.org> wrote: > >> On Jan 9, 2018, at 11:30 PM, Saagar Jha <saa...@saagarjha.com> wrote: >>> >>> In short, can we change playgroundRepresentation to return Any instead of >>> Any?. Among other things, doing so could ease the case of playground >>> formatting Optional itself, which should presumably get a conditional >>> conformance to this. :-) >> >> I believe the rationale behind this was to provide a way to “opt-out” of a >> customized representation, although now that I think about it, what exactly >> does the default mean? In particular, what happens in this case? > > If you want a type to display as nothing (e.g. to avoid the perf impact of > formatting it) just make the playground representation be an empty string or > something. > > -Chris > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
