[Blog Post] The Two Faces of Codable/Serde

I've had an insight about Codable (and Rust's Serde) that seemed interesting enough to share. Happy to hear everyone's thoughts!

16 Likes

I think that the second aspect you mention is (unfortunately) often de-emphasized and strong support for type ser/des, preferably with in-place zero-copy type instance construction if/when possible would be helpful for some cases (basically providing a facade for the underlying raw data). I think that is a separate question too - often the discussion is how to ser/des, but sometimes one just would like a nice language level type wrapper how to access the underlying raw data - cf. Google flatbuffers.

I’m coming from a different background where json serialization is a nice-to-have feature, but the bread and butter is a plethora of binary protocols (dozens), with a common need to describe type ser/des with efficiency.

Support for building efficient type ser/des that can be pluggable into a parser generator (perhaps a result builder being used for declarative descriptions?) would be a nice tool to have in the box.

Sorry, bit of a sidetrack perhaps, but I hope there’d be room for a wider view of what is desirable use cases for ser/des (and not just limiting it to a tree representation of a type graph) if it is being reconsidered.

It’s interesting because I think of the second use case—a library vending a type—as one where you can’t guarantee efficiency, because you don’t know what format your type is going to be used with. So I didn’t expect you to link them immediately with zero-copy deserialization. That said, I can’t see a technical reason why you can’t get sharing-like behavior in the current decoding system for fields of type Substring, Data, or (*gasp*) UnsafeRawBufferPointer, if your decoder special-cases them the same way JSONDecoder special-cases Date. Wholescale C-style “reinterpret a buffer pointer as a struct pointer” is a lot further away, though, since Swift does not have a supported way to control the layout of structs defined in Swift, and does not like having memory treated as different types.

EDIT: and FlatBuffers does seem like a different kind of code generation to me, since decoding is lazy. But it’s an interesting one for sure.

For what it's worth there has not been much innovation in this space in Swift because of lacking metaprogramming capabilities IMHO -- but with the upcoming macros, that's about to change. I'm myself pretty hopeful for various specialized serializers to pop up, that may or may not (!) look similar to Codable at all.

6 Likes