Anviking / Decodable

[Probably deprecated] Swift 2/3 JSON unmarshalling done (more) right
MIT License
1.04k stars 73 forks source link

Remove default `Decodable` extensions #138

Open Anviking opened 7 years ago

Anviking commented 7 years ago

Re: #137

Extensions that can be removed

Extensions that cannot be removed

These cannot be removed completely, because Array.decoder and others use them. The question here is rather if they should be DynamicDecodable or "fixed".

voidref commented 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?

Anviking commented 7 years ago

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.