I have a new pitch available for adding additional CodableWithConfiguration support to Foundation's top-level encoder/decoders. Please feel free to let me know if you have any comments or suggestions!
Currently, the TopLevelEncoder /TopLevelDecoder protocols along with Foundation's conformers (JSONEncoder , JSONDecoder , PropertyListEncoder , and PropertyListDecoder ) offer an encode /decode function that accepts some Codable instance. In previous releases, we also introduced the CodableWithConfiguration protocol (which is now used by AttributedString and Predicate in Foundation) to allow for encoding/decoding types with extra provided information. Currently, CodableWithConfiguration types cannot be directly encoded/decoded by Foundation's coders. Instead, callers must wrap their CodableWithConfiguration type within a separate Codable type to provide to a coder like JSONEncoder . While in many cases this may already be necessary, in some cases this is unnecessary extra work developers must do in order to get started with serializing these types. With new adoption of CodableWithConfiguration for Predicate this year, we'd like to improve this experience.
Hi @jmschonfeld could you update the pitch with a code example of the current way (wrapping in a box type) for better comparison? Maybe even using the CodableTypeWithConfiguration that you've used in the tests. Thanks!
Wonderful! I have a question: Could these new encode and decode functions be annotated with the @backDeployed attribute to be used in iOS 15+, when CodableWithConfiguration was introduced?
Unfortunately, these functions are not able to be back deployed for a similar reason as why we are unable to implement them generically for some TopLevelEncoder/some TopLevelDecoder. Back deploying these functions would require that the entry points they use were available in these back deployed versions. Since these functions call into internal class implementations that are not ABI nor externally accessible on prior versions, the back deployed versions of these functions would not have the entry points they need to operate.
Apologies for the late reply. The pitch says in Alternatives considered:
Providing Additional API on TopLevelEncoder/TopLevelDecoder
Ideally, the generic protocols TopLevelEncoder & TopLevelDecoder would also have functions that accept CodableWithConfiguration types. However, given that these are already-shipping protocols we cannot add a new requirement without also providing a default implementation.
Correct me if I'm wrong, but as far as I can tell, the TopLevelEncoder and TopLevelDecoder protocols defined in Apple's proprietary Combine framework. So they're not part of the Swift toolchain.
Doesn't this give us an opportunity to reintroduce new protocols (maybe under a different name, maybe not) that serve the same purpose to Foundation or even the standard lib?
