<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">If we generate a default <span class="Apple-tab-span" style="white-space: pre;"> </span>• debugDescription for encodable type, I would rather use a human readable formatted string that explicitly do not guarantee to remain stable.<div class=""><br class=""></div><div class="">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.</div><div class="">Maybe we need a custom encoder that uses debugDescription on each field.</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">Le 13 juil. 2017 à 01:45, Itai Ferber via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8" class="">
<div class="">
<div style="font-family:sans-serif" class=""><div style="white-space:normal" class=""><p dir="auto" class="">This would be possible, but I have the following concerns about doing something like this:</p>
<ul class="">
<li class="">This would only be available when Foundation is imported (since this would require access to <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7" class="">JSONEncoder</code>). This could make debugging confusing if you don’t always import Foundation</li>
<li class="">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 <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7" class="">Double.infinity</code> which is unrepresentable in JSON)</li>
<li class="">From some experience, I feel like this could lead to easy abuse of conversion to JSON (what’s easier, creating a <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7" class="">JSONEncoder</code> and encoding, or asking for the <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7" class="">debugDescription</code> on a type?)… Once people start relying on this, too, we’ll have compatibility problems if we ever want to change the format</li>
<li class="">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… 😬</li>
</ul><p dir="auto" class="">Interested in hearing more thoughts and input, though!</p><p dir="auto" class="">On 12 Jul 2017, at 15:51, William Shipley via swift-evolution wrote:</p>
</div>
<div style="white-space:normal" class=""><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px" class=""><p dir="auto" class="">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?<br class="">
<br class="">
Any drawbacks to doing this?<br class="">
<br class="">
-Wil<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="color:#777" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></p>
</blockquote></div>
<div style="white-space:normal" class="">
</div>
</div>
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>