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!
TopLevelDecoder protocols along with Foundation's conformers (
PropertyListEncoder , and
PropertyListDecoder ) offer an
decode function that accepts
some Codable instance. In previous releases, we also introduced the
CodableWithConfiguration protocol (which is now used by
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
Predicate this year, we'd like to improve this experience.
You can read the full pitch at the gist here and check out the implementation PR here.
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!
Sure thing! I've added that to the linked pitch for context on how this would be written with today's APIs.
Wonderful! I have a question: Could these new
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 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
Ideally, the generic protocols
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
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?