[swift-evolution] [Proposal] Revamp the playground quicklook APIs

[Riley Testut]

> On Jan 9, 2018, at 10:02 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:


> What is the use-case for a type conforming to this protocol but returning nil?  If there is a use case for that, why not have such an implementation return “self” instead?

I assumed it could be used if a type’s playground representation was variable. For instance:

enum MyUnion
{
    case string(String)
    case image(UIImage)
    case none
}

In its implementation of CustomPlaygroundRepresentable, it could return a string if case string, an image if case image, or return nil if case none to just do whatever is the default for enum values. 

Admittedly the above is a very contrived example, but I do think it is important to allow types to opt-out.

> On Jan 9, 2018, at 10:02 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Jan 9, 2018, at 3:19 PM, Connor Wakamo via swift-evolution <swift-evolution at swift.org> wrote:
>> Good afternoon,
> 
> Hi Connor,
> 
> Huge +1 for this proposal, I’m thrilled you’re cleaning this up.  Couple of detail questions:
> 
>> Detailed design
>> 
>> To provide a more flexible API, we propose deprecating and ultimately removing the PlaygroundQuickLook enum and CustomPlaygroundQuickLookable protocol in favor of a simpler design. Instead, we propose introducing a protocol which just provides the ability to return an Any (or nil) that serves as a stand-in for the instance being logged:
>> 
> 
> What is the use-case for a type conforming to this protocol but returning nil?  If there is a use case for that, why not have such an implementation return “self” instead?
> 
> 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.  :-)
> 
> 
>> /// Implementors of `CustomPlaygroundRepresentable` may return a value of one of
>> /// the above types to also receive a specialized log representation.
>> /// Implementors may also return any other type, and playground logging will
>> /// generated structured logging for the returned value.
>> public protocol CustomPlaygroundRepresentable {
> 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.  As such, have you considered CustomPlaygroundConvertible for consistency with it?
> 
> The only prior art for the word “Representable” in the standard library is RawRepresentable, which is quite a different concept.
> 
>>   /// Returns the custom playground representation for this instance, or nil if
>>   /// the default representation should be used.
>>   ///
>>   /// If this type has value semantics, the instance returned should be
>>   /// unaffected by subsequent mutations if possible.
>>   var playgroundRepresentation: Any? { get }
> Again to align with CustomStringConvertible which has a ‘description’ member, it might make sense to name this member “playgroundDescription”.
> 
> Thank you again for pushing this forward, this will be much cleaner!
> 
> -Chris
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180110/ccfc067a/attachment.html>