[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