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