<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Jan 10, 2018, at 2:10 PM, Connor Wakamo &lt;<a href="mailto:cwakamo@apple.com" class="">cwakamo@apple.com</a>&gt; wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class="">What is the use-case for a type conforming to this protocol but returning nil? &nbsp;If there is a use case for that, why not have such an implementation return “self” instead?</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Riley and Saagar answered this down-thread, but to confirm — returning nil would allow some instances of a type to use the “default” playground logging presentation while others use an alternate presentation instead.</div></div></div></div></blockquote><div><br class=""></div><div>Right, this gets back to the question: what is the use case for this? &nbsp;When would a type want to “sometimes” replace the default representation?</div><div><br class=""></div><div>It seems to me that a type author either wants to take control of presentation or not. &nbsp;While I’m sure we could imagine some use case for the behavior you’re describing, is it big enough to make it worth complicating the API?</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class="">This isn’t handled by `return self` because, unless I’m mistaken, there’s no way to detect that from the caller’s side (e.g. with two `Any` values, I can’t do `self === self.playgroundRepresentation`). </div></div></div></div></blockquote><div><br class=""></div><div>Ok</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class="">In short, can we change&nbsp;playgroundRepresentation to return Any instead of Any?. &nbsp;Among other things, doing so could ease the case of playground formatting Optional itself, which should presumably get a conditional conformance to this. &nbsp;:-)</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I don’t think we can change this to return `Any` instead of `Any?`. I think there are potentially cases where a developer might want to selectively opt-in to this behavior.</div></div></div></div></blockquote><div><br class=""></div>Which cases? &nbsp;How important are they?</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class="">I also don’t think that `Optional` would get a conditional conformance to this. I’m not proposing that any standard library or corelibs types gain conformances to this protocol. Instead, it’s up to a playground logger (such as PlaygroundLogger in&nbsp;<a href="https://github.com/apple/swift-xcode-playground-support" class="">swift-xcode-playground-support</a>) to recognize these types and handle them accordingly. The playground logger would look through the `Optional` so that this would effectively be true, but ideally the log data generated by a logger would indicate that it was wrapped by `Optional.some`.</div></div></div></div></blockquote><div><br class=""></div><div>Why not? &nbsp;I understand that that is how the old algorithm worked, but it contained a lot of special case hacks due to the state of Swift 1 :-). &nbsp;This is a chance to dissolve those away.</div><div><br class=""></div><div>To be clear, I would expect that the conformance for optional would be defined in the playground module along with this protocol - it wouldn’t be defined in the standard library itself.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class=""><div class="">One possibility would be to change the API so that it returns an enum. Imagine:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>enum PlaygroundLoggingBehavior {</div><div class=""><span class="Apple-tab-span" style="white-space: pre;">                </span>/// Asks the playground logger to generate the standard logging for `self`.</div><div class=""><span class="Apple-tab-span" style="white-space: pre;">                </span>case standard</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;">                </span>/// Asks the playground logger to generate logging for the given `Any` instead of `self`.</div><div class=""><span class="Apple-tab-span" style="white-space: pre;">                </span>case custom(Any)</div><div class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>}</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>protocol CustomPlaygroundLoggable {</div><div class=""><span class="Apple-tab-span" style="white-space: pre;">                </span>/// Returns the `PlaygroundLoggingBehavior` to use for `self`.</div><div class=""><span class="Apple-tab-span" style="white-space: pre;">                </span>var playgroundLoggingBehavior: PlaygroundLoggingBehavior { get }</div><div class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>}</div><div class=""><br class=""></div><div class="">(To Saagar’s point in another email — you could even add a `case none` to PlaygroundLoggingBehavior to inhibit logging of a particular instance.)</div><div class=""><br class=""></div><div class="">`CustomPlaygroundLoggable` would be a little clunkier to implement than `CustomPlaygroundRepresentable` is, as in the common case folks would have to write `return .custom(…)`. It’s possible that the clarity and additional flexibility this grants outweighs that cost; I’m not sure, and would love feedback on that.</div></div></div></div></div></blockquote><div><br class=""></div><div>I just don’t understand the usecase for “conditional customizing” at all. &nbsp;By way of example, we don’t have the ability to do that with&nbsp;CustomStringConvertible. &nbsp; What is different about this case?</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class="highlight highlight-source-swift" style="box-sizing: border-box; margin-bottom: 16px; color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Helvetica, Arial, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, &quot;Segoe UI Symbol&quot;; font-size: 16px; background-color: rgb(255, 255, 255);"><pre style="box-sizing: border-box; font-family: SFMono-Regular, Consolas, &quot;Liberation Mono&quot;, Menlo, Courier, monospace; font-size: 13.600000381469727px; margin-top: 0px; margin-bottom: 0px; word-wrap: normal; padding: 16px; overflow: auto; line-height: 1.45; background-color: rgb(246, 248, 250); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-break: normal;" class=""><span class="pl-c" style="box-sizing: border-box; color: rgb(106, 115, 125);"><span class="pl-c" style="box-sizing: border-box;">///</span> Implementors of `CustomPlaygroundRepresentable` may return a value of one of</span>
<span class="pl-c" style="box-sizing: border-box; color: rgb(106, 115, 125);"><span class="pl-c" style="box-sizing: border-box;">///</span> the above types to also receive a specialized log representation.</span>
<span class="pl-c" style="box-sizing: border-box; color: rgb(106, 115, 125);"><span class="pl-c" style="box-sizing: border-box;">///</span> Implementors may also return any other type, and playground logging will</span>
<span class="pl-c" style="box-sizing: border-box; color: rgb(106, 115, 125);"><span class="pl-c" style="box-sizing: border-box;">///</span> generated structured logging for the returned value.</span>
<span class="pl-c" style="box-sizing: border-box; color: rgb(106, 115, 125);"></span><span class="pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">public</span> <span class="pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">protocol</span> <span class="pl-en" style="box-sizing: border-box; color: rgb(111, 66, 193);">CustomPlaygroundRepresentable</span> {
</pre></div></div></div></blockquote><div class="">On the naming bikeshed, the closest analog to this feature is CustomStringConvertible, which is used when a type wants to customize the default conversion to string. &nbsp;As such, have you considered CustomPlaygroundConvertible for consistency with it?</div><div class=""><br class=""></div><div class="">The only prior art for the word “Representable” in the standard library is RawRepresentable, which is quite a different concept.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class="highlight highlight-source-swift" style="box-sizing: border-box; margin-bottom: 16px; color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Helvetica, Arial, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, &quot;Segoe UI Symbol&quot;; font-size: 16px; background-color: rgb(255, 255, 255);"><pre style="box-sizing: border-box; font-family: SFMono-Regular, Consolas, &quot;Liberation Mono&quot;, Menlo, Courier, monospace; font-size: 13.600000381469727px; margin-top: 0px; margin-bottom: 0px; word-wrap: normal; padding: 16px; overflow: auto; line-height: 1.45; background-color: rgb(246, 248, 250); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-break: normal;" class="">  <span class="pl-c" style="box-sizing: border-box; color: rgb(106, 115, 125);"><span class="pl-c" style="box-sizing: border-box;">///</span> Returns the custom playground representation for this instance, or nil if</span>
<span class="pl-c" style="box-sizing: border-box; color: rgb(106, 115, 125);"></span>  <span class="pl-c" style="box-sizing: border-box; color: rgb(106, 115, 125);"><span class="pl-c" style="box-sizing: border-box;">///</span> the default representation should be used.</span>
<span class="pl-c" style="box-sizing: border-box; color: rgb(106, 115, 125);"></span>  <span class="pl-c" style="box-sizing: border-box; color: rgb(106, 115, 125);">///</span>
<span class="pl-c" style="box-sizing: border-box; color: rgb(106, 115, 125);"></span>  <span class="pl-c" style="box-sizing: border-box; color: rgb(106, 115, 125);"><span class="pl-c" style="box-sizing: border-box;">///</span> If this type has value semantics, the instance returned should be</span>
<span class="pl-c" style="box-sizing: border-box; color: rgb(106, 115, 125);"></span>  <span class="pl-c" style="box-sizing: border-box; color: rgb(106, 115, 125);"><span class="pl-c" style="box-sizing: border-box;">///</span> unaffected by subsequent mutations if possible.</span>
<span class="pl-c" style="box-sizing: border-box; color: rgb(106, 115, 125);"></span>  <span class="pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">var</span> playgroundRepresentation<span class="pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">:</span> <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 92, 197);">Any</span><span class="pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">?</span> { <span class="pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">get</span> }
</pre></div></div></div></blockquote><div class="">Again to align with&nbsp;CustomStringConvertible which has a ‘description’ member, it might make sense to name this member “playgroundDescription”.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I’m definitely open to different names for this. (`CustomPlaygroundRepresentable` was inspired by the API I’m removing, `CustomPlaygroundQuickLookable`, as they both take their sole property and make them -able.)</div><div class=""><br class=""></div><div class="">I do like the `playgroundDescription` name for the property, but am a little hesitant to use the name `CustomPlaygroundConvertible` because conforming types can’t be converted to playgrounds. I can’t come up with an appropriate word in `CustomPlaygroundThingConvertible` to use in place of `Thing`, though. (If we end up pivoting to the enum I described above then something like `CustomPlaygroundLoggable` would be more appropriate.)</div></div></div></div></blockquote><br class=""></div><div>I would strongly recommend aligning with the state of the art in&nbsp;CustomStringConvertible (which has been extensively discussed) and ignore the precedent in the existing playground logging stuff (which hasn’t).</div><div><br class=""></div><div>-Chris</div><div><br class=""></div><br class=""></body></html>