> On Jan 9, 2018, at 10:02 PM, Chris Lattner via swift-evolution
> <swift-evolution@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@swift.org> wrote:
>
>> On Jan 9, 2018, at 3:19 PM, Connor Wakamo via swift-evolution
>> <swift-evolution@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
