[swift-evolution] Idea: Use <Codable> for default implementation of <CustomDebugStringConvertible>?

[Jean-Daniel]

If we generate a default 	• debugDescription for encodable type, I would rather use a human readable formatted string that explicitly do not guarantee to remain stable.

JSON is very limited in the types it supports (it does not even supports date natively). A debug description should not suffer the limitation of the output format.
Maybe we need a custom encoder that uses debugDescription on each field.


> Le 13 juil. 2017 à 01:45, Itai Ferber via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> This would be possible, but I have the following concerns about doing something like this:
> 
> This would only be available when Foundation is imported (since this would require access to JSONEncoder). This could make debugging confusing if you don’t always import Foundation
> What do you get when encoding a value fails? Or for values which would otherwise require a strategy to encode correctly? (e.g. you’ve got a property whose value is Double.infinity which is unrepresentable in JSON)
> From some experience, I feel like this could lead to easy abuse of conversion to JSON (what’s easier, creating a JSONEncoder and encoding, or asking for the debugDescription on a type?)… Once people start relying on this, too, we’ll have compatibility problems if we ever want to change the format
> And along with that, I don’t necessarily feel comfortable with promoting JSON in this way. It’s very popular today, but then again, there was a time where XML was the format du jour… 😬
> Interested in hearing more thoughts and input, though!
> 
> On 12 Jul 2017, at 15:51, William Shipley via swift-evolution wrote:
> 
> Would it be possible for items that implement <Codable> to automatically get <CustomDebugStringConvertible> with a default implementation that just calls encode into a JSON blob and then dumps it to the screen?
> 
> Any drawbacks to doing this?
> 
> -Wil
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> 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/20170714/daf99239/attachment.html>