"New Codable" prototype available for feedback

[tera]

@Matt_Gallagher

But moreover, while you might make archive-specific choices, you don't always have archive-specific knowledge. Take for example, trying to decode a value from an archive that might include any common "property tree" value:

public init(from decoder: Decoder) throws {
    let container = try decoder.singleValueContainer()
    if container.decodeNil() {
        self = .null
    } else if let stringValue = try? container.decode(String.self) {
        self = .string(stringValue)
    } else if let intValue = try? container.decode(Int.self) {
        self = .integer(intValue)
    } else if let doubleValue = try? container.decode(Double.self) {
        self = .double(doubleValue)
    } else if let boolValue = try? container.decode(Bool.self) {
        self = .boolean(boolValue)
    } else if let array = try? container.decode([DatabaseLiteralValue].self) {
        self = .array(try JSONEncoder().encode(array))
    } else {
        self = .object(try JSONEncoder().encode(container.decode([String: DatabaseLiteralValue].self)))
    }
}

We have no lookahead. We can't peek to see if the next char is a double-quote, a digit or a bracket. Without overloading the Decoder to emit lookahead metadata as decodable types, you simply need to try each possibility, in turn, incurring the overhead and disruption of thrown errors.

Yeah, there are quite some limitations here... Note how you had to put decoding Int before decoding Double. Or what if there was a Float in one case's payload and Double in another, or String in one and StringProtocol type in another. The limitations are more serious that just that, e.g, you might have an enum with:

enum E {
    case a(A)
    case b(B)
    ...
}

where A and B are similar types as far as decoding is concerned:

// example
struct A { let x: UInt }
struct B { let x: Int }

or a more complicated case:

enum E {
    case a([A])
    case b([B])
    ...
}

with the payload to decode being an array of 100K positive elements and the last element being negative.

Ideally type information should be available during decoding one way or another... JSON won't be able preserving that (aside from embedding extra information in some custom way) but other serialisation formats (like XML) will be able preserving it.