This request ultimately doesn't make sense because of what happens on the decode side. Unlike NSCoding, Codable doesn't include any information about the type of a value in the encoded representation. That means you can't actually decode the data, because you don't know what dynamic type to use.

Type erasure works with Encodable, but even there you lose out on possible specialized representations for a particular value—for instance, a string-keyed dictionary and an "AnyEncodable"-keyed dictionary are encoded differently, even if the AnyEncodable values all happen to be strings.

@itaiferber can explain further if you have more questions.

Comment by Peter Kamb (JIRA)

Yeah, I understand why it doesn't / won't work with the current implementation of Codable.

But this seems like a pretty severe limitation in our "protocol-oriented programming language"...?

This basically makes it extremely complicated / untenable to use Protocols in data models.

Codable and Protocols are both pretty basic Swift building blocks, but using them together results in a nasty rabbit hole of type erasure, broken Codable synthesis, dynamic types, etc. No way to eliminate that hurdle?

Comment by Peter Kamb (JIRA)

It feels like this could "just work" via the introduction of synthesized code that replicated the approach taken in the Stack Overflow answer. Perhaps with a single required enum that mapped keys to decodable types.

enum MediaType : String, Codable {
    case book
    case movie

    var metatype: Tag.Type {
        switch self {
        case .book:  return Book.self
        case .movie: return Movie.self
        }
    }
}