I was really disappointed to see this, because these are probably my two major pain points with Codable.
If we are going to the trouble of making a brand new, backwards-incompatible replacement for Codable then it should try to correct all the major deficiencies of the existing design, not just performance.
NSCoding (for all its faults) supports both or heterogeneous data and cyclical references. If this new system doesn't support those then we are saying from the outset that it is still isn't going to be capable of dealing with a lot of real-world use-cases.
I understand the security implications of including type information in serialized data, but it's a super-common real-world use-case and if it's not a built-in feature then it should at the very least have first-class support for people who want to create their own such systems without starting from scratch.
Two very common patterns that I'd like to see supported out of the box are:
@JSONCodable
enum PolymorphicPrimitive {
case string(String)
case int(Int)
}
and:
@JSONCodable
protocol PolymorphicObject {
@CodableTypeKey
let type: String
...
}
If CodableTypeKey needs to be an enum, or accept a fixed array of types as a parameter then so be it (although it would ideally allow any type that conforms to the protocol to support runtime registration of new types via plugins, etc).