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

Itai Ferber iferber at apple.com
Wed Jul 12 18:45:05 CDT 2017


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170712/1027330c/attachment.html>


More information about the swift-evolution mailing list