<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="">And all of this is only an issue if you write the conformance by hand in the first place. Usually, you won't.</div></div></blockquote></div><br class=""><div class="">Brent, given that this API is designed not just for NSKeyedArchiver-like usage, but to form the basis of serialization to and from JSON, among other network types, I really don’t think this is true. It just won’t work by default for JSON, if only because JSON has informally standardized on snake-case keys (some_key). AFAICT, this proposal has nothing to enable developers to define a key convention that automatically generates such keys. So, from my perspective, every single use of the proposed APIs that isn’t just a replacement for NSKeyedArchiver will be forced to manually implement the entire API, unless developers get lucky and somehow get a representation that fits a good Swift type exactly. That just doesn’t happen. There are so many bad JSON APIs out there that being able to easily define different keys and transforms of a JSON type to some Swift type isn’t just a convenience, it’s a requirement.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Jon Shier</div></body></html>