[Pitch] Top Level Coder Support for CodableWithConfiguration

Related Projects Foundation
1

Hi all,

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.

You can read the full pitch at the gist here and check out the implementation PR here.

7 Likes
2

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!

3

Sure thing! I've added that to the linked pitch for context on how this would be written with today's APIs.

1 Like
4

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?

5

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.

1 Like
6

I see :smiling_face_with_tear: