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 
> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to