{"id":23995,"date":"2019-01-18T14:48:29","date_gmt":"2019-01-18T19:48:29","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=23995"},"modified":"2019-01-24T16:07:49","modified_gmt":"2019-01-24T21:07:49","slug":"even-more-about-swifts-codable","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2019\/01\/18\/even-more-about-swifts-codable\/","title":{"rendered":"Even More About Swift’s Codable"},"content":{"rendered":"

Ben Scheirman<\/a> (via Kuba Suder<\/a>):<\/p>\n

\n

Instead, we can use a special method to get a super-class ready encoder that already has a container attached to it[…]<\/p>\n

[…]<\/p>\n

Here we have a migration_date<\/code> field that has a different date format than the created_at<\/code> field. Let’s also assume that the name property has since been changed to just name<\/code>.<\/p>\n

This is obviously not an ideal situation, but real-life happens and sometimes you inherit a messy API.<\/p>\n

[…]<\/p>\n

This is a listing of beer styles, but the keys are actually the name of the style.\nWe could not represent every possible case<\/em> with an enum as it could change or grow over time.<\/p>\n

Instead, we can create a more dynamic implementation of CodingKey<\/code> for this.<\/p>\n<\/blockquote>\n

This is the most comprehensive guide to Codable<\/code> and JSON that I’ve seen.<\/p>\n\n

Russ Bishop<\/a>:<\/p>\n

\n

The new Codable<\/code> protocol is flexible enough to allow a different encoded representation from the in-memory representation which is a nice property to have in a serialization mechanism. Today I’m going to build SingleValueCodable<\/code> to automate that work when dealing with RawRepresentable<\/code> types.<\/p>\n<\/blockquote>\n\n

Ole Begemann<\/a>:<\/p>\n

\n

So Dictionary<\/code> seems to behave differently depending on its Key<\/code> type, even though the enum values are ultimately encoded as strings. What’s going on here? We can find the answer in Dictionary<\/code>’s implementation<\/a> for the Encodable<\/code><\/a> protocol.<\/p>\n

[…]<\/p>\n

There are three branches: only if the dictionary’s key type is String<\/code> or Int<\/code> does it use a keyed container. Any other key type triggers results in an unkeyed container of alternating keys and values.<\/p>\n<\/blockquote>\n\n

SE-0239<\/a>:<\/p>\n

\n

SE-0167<\/a> introduced Codable<\/code> conformance for some types in the standard\nlibrary, but not the Range<\/code> family of types. This proposal adds that\nconformance.<\/p>\n<\/blockquote>\n\n

There’s quite an interesting discussion<\/a> about this, because the details of how it works will end up affecting databases and APIs outside of Swift itself.<\/p>\n\n

Paul Samuels<\/a>:<\/p>\n

\n

The two key takeaways here are<\/p>\n