Open Anviking opened 7 years ago
I haven't thought about it too much, but it seems a shame to lose a bunch of functionality.
I wonder if they can be separated out and imported piecemeal, as desired, instead.
If we do a big change like this, how many projects is it going to break, how bad will it be, and what can be done to mitigate it.
Something like import DecodableTypeExtensions
or something?
I imagined copy-pasting code as an acceptable solution here if the code could be kept short. Maybe there is some problem with this I haven't thought about, but moving the extensions to a different module seems overkill.
For the castable types it's quite simple:
extension String: Castable {}
extension Int: Castable {}
extension Double: Castable {}
extension Bool: Castable {}
For other types, like URL
and Date
one could do a couple things like
extension Date: Decodable {
static func decode(_ json: Any) throws -> Date {
return try formatter.decode(json)
}
}
and/or adding a helper protocol with default implementation so that this works
extension Date: DecodableFromISO8601DateString {}
but I think it mostly would be obscure and confusing.
Re: #137
Extensions that can be removed
Date
URL
String
Int
Double
Bool
Extensions that cannot be removed
NSDictionary
NSArray
These cannot be removed completely, because
Array.decoder
and others use them. The question here is rather if they should beDynamicDecodable
or "fixed".