\n<\/p>\n
Kevin Perry<\/a>:<\/p>\n It\u2019s clear from community adoption and feedback that [\u2026]<\/p>\n Even with all of its strengths, the existing API\u2019s design has some unavoidable performance penalties. For instance, its use of existentials implies additional runtime and memory costs as existential values are boxed, unboxed, retained, released, and dynamic dispatch is performed.<\/p>\n Also, because a client can decode dictionary values in arbitrary orders, a [\u2026]<\/p>\n In Swift, when a client needs to do more than just alter the default [\u2026]<\/p>\n In this new design I aim to leverage Swift\u2019s macro features to meet or exceed Serde\u2019s level of support for customization of synthesized conformances. Moving code synthesis from the compiler to a macro will enable us to use attribute-like macros as targeted customization mechanisms, which was not something we could easily accomplish with the compiler-based [\u2026]<\/p>\n There is no I believe that fully and formally embracing format-specialization where appropriate is the best solution to this problem. Specifically, we should encourage each serialization format that has native support for data types that aren\u2019t represented in the format-agnostic interface to produce its own protocol variant that includes explicit support for these types, e.g. Dave DeLong<\/a> (Mastodon<\/a>):<\/p>\n One of the big flaws of That design flaw has been the #1 source of Codable\u2019s woes. It makes properly implementing custom coders almost impossible; no one implements [\u2026]<\/p>\n IMO we should be encouraging packages that provide format-specific coders ( [\u2026]<\/p>\n Foundation should provide an updated replacement for Kevin Perry<\/a>:<\/p>\n At one stage, the \u201cformat specialized\u201d protocols was the entirety of the design. However, while looking at adoption scenarios, I realized that this design presented a problem with \u201ccurrency\u201d types that are owned by frameworks\/libraries, but used by application-level serializable types.<\/p>\n [\u2026]<\/p>\n Hence the introduction of the format-agnostic protocols in parallel with the format-specialized ones. Dave DeLong<\/a>:<\/p>\n That\u2019s why I\u2019m suggesting that we split the API to support the cases separately. We have one API that can be very general and support the whole \u201cA type can be serialized to an opaque format\u201d use-case, and then packages to support particular formats and all of their respective idiosyncrasies. I think we\u2019d be repeating past mistakes to try and make those two use cases be the same<\/em> API again.<\/p>\n<\/blockquote>\n Lincoln Wu<\/a>:<\/p>\n I think there\u2019s one common use case which is not covered by the current Many times in my developing, I wanted to decode part of a json into an intermediate representation, and later further decode that thing into a specific type.<\/p>\n<\/blockquote>\n Matt Gallagher<\/a>:<\/p>\n The problem with But moreover, while you might make archive-specific choices, you don\u2019t always have archive-specific knowledge.<\/p>\n [\u2026]<\/p>\n We have no lookahead. We can\u2019t peek to see if the next char is a double-quote, a digit or a bracket. Without overloading the Kevin Perry<\/a>:<\/p>\n This design does not include support for encoding and decoding cyclical objects graphs. Relatedly, there\u2019s still no intention to include encoding of runtime type information in serialization formats for any purpose\u2014all concrete types must be specified by the client doing the encoding or decoding.<\/p>\n<\/blockquote>\n Nick Lockwood<\/a>:<\/p>\n I was really disappointed to see this, because these are probably my two major pain points with If we are going to the trouble of making a brand new, backwards-incompatible replacement for [\u2026]<\/p>\n Also (related) some kind of built-in support for schema updates and migrations (similar to CoreData\/SwiftData) would be a great feature, as this is another pain point in Codable.<\/p>\n Even just a way to specify a default value for new non-optional properties would reduce a lot of the need for adding manual decoder implementations to apps in post-1.0 releases.<\/p>\n<\/blockquote>\n Helge He\u00df<\/a>:<\/p>\n Nick Lockwood<\/a>:<\/p>\n Another issue I\u2019ve run into with \n
Codable<\/code> has had a lot of success in the years since it was added to Swift 4, but that it doesn\u2019t satisfy some important needs. One of the foremost of those needs is performance more in line with programming environments that compete with Swift. As such, the main goal for this effort is to unlock higher levels of performance during both serialization and deserialization without sacrificing the ease of use that Codable<\/code> provides.<\/p>\nKeyedDecodingContainer<\/code> is effectively required to proactively parse the payload into some kind of intermediate representation, necessitating allocations for internal temporary dictionaries, and String<\/code> values.<\/p>\nCodingKey<\/code> representations, developers are often faced with a large cliff where they\u2019re forced to manually replicate the whole Codable<\/code> implementation just to do so.<\/p>\nCodable<\/code> synthesis.<\/p>\nencode(_: Date)<\/code> function present in the Encoder<\/code> interface, which means PropertyListEncoder<\/code> has to attempt to dynamically cast<\/a> every some Encodable<\/code> type it receives to Date<\/code> in order to handle these natively. This helps keep the Encodable<\/code> type format-agnostic, but it has a negative impact on performance, even if you never actually encode any Date<\/code>s.<\/p>\nJSONCodable<\/code> or PropertyListCodable<\/code>.<\/p>\n<\/blockquote>\n\n
Codable<\/code> is that it was built on the wrong abstraction. 99.9% of the time, developers who are interested in serializing a struct to data and back are doing so to a single, well-known format. However, the Codable<\/code> API was built so that the abstraction point is the encoder itself, under the assumption that you would want to serialize a type to multiple<\/em> formats. This is not the case.<\/p>\nsuperEncoder<\/code> properly, since most people don\u2019t deal with inheritance of reference types, and some formats are fundamentally incompatible with the Encoder\/Decoder APIs. (XML and CSV are two that spring to mind off the top of my head)<\/p>\nJSONCodable<\/code>, PlistCodable<\/code>, CSVCodable<\/code>, XMLCodable<\/code>, etc) so that each encoder and decoder can provide format-specific functionality. Then we should provide a system level API to ask types to encode into an opaque<\/em> format (ie \u201cplease turn yourself into a Data<\/code> and back again\u201d).<\/p>\nNSCoding<\/code> and leave the type-specific encoders to type-specific packages to implement.<\/p>\n<\/blockquote>\n\n
JSONCodable<\/code>, PlistCodable<\/code>, etc. should have full freedom to craft their interface around each format\u2019s individuals needs and specialities.<\/p>\nRange<\/code> and CGRect<\/code> can, in similar fashion to Codable<\/code>, describe their serializable members abstractly, allowing a specific encoder\/decoder to interpret those instructions. The difference from Codable<\/code> being that we avoid all the OTHER downsides of Codable<\/code> the OP describes.<\/p>\n<\/blockquote>\n\n
\n
Codable<\/code> design: heterogeneous\/dynamic decoding\/encoding.<\/p>\n\n
Codable<\/code> \u2013 and what I think you\u2019re getting at when you suggest we need JSONCodable<\/code>\/PlistCodable<\/code> \u2013 is there\u2019s no sane custom implementation of init(from:)<\/code> and encode(to:)<\/code> without being archive-specific. These functions are generally a mashup of two different ideas:<\/p>\n\n
Decoder<\/code> to emit lookahead metadata as decodable types, you simply need to try each possibility, in turn, incurring the overhead and disruption of thrown errors.<\/p>\n<\/blockquote>\n\n
\n
Codable<\/code>.<\/p>\nCodable<\/code> then it should try to correct all the major deficiencies of the existing design, not just performance.<\/p>\nNSCoding<\/code> (for all its faults) supports both or heterogeneous data and cyclical references. If this new system doesn\u2019t support those then we are saying from the outset that it is still isn\u2019t going to be capable of dealing with a lot of real-world use-cases.<\/p>\n\n
NSCoder<\/code>\/NSArchiver<\/code> was actually pretty good for what it was intended for, archiving object graphs. How can I do that today? SwiftData? \ud83d\ude48<\/p>\n<\/blockquote>\n\n
Codable<\/code> is that a given object may have more than one serialized representation in a given application.<\/p>\n<\/blockquote>\n