Here is a great article on using it: https://medium.com/swiftly-swift/swift-4-decodable-beyond-th....

Author of the article here! Thank you for the kind words and thanks for sharing!

I was wondering why that entry had a huge spike on reads yesterday :D (1500 reads against a daily average of 200).

Glad I could help. Thank you for writing it!

Thats for this article. I have it on my list of things to read on my way to work!!!

Am I the only one who thinks it's weird that Codable is a magic interface? Are there any other "magic" interfaces?

It's not that weird - it's simply that Swift currently has no meta-programming features, in the interest of focusing on many other aspects of the language. As a result, Codable had to be baked directly into the language, or uses private reflection APIs not available to the public.

Objective-C does have meta-programming features [0] and that's how all the really nifty features were made possible (KVO, CoreData, etc)

What Swift is aiming for, is to be a performant, general purpose programming language. This restrains it in the amount of clever stuff you can do. That and the inter-op requirement has been an incredible hurdle when it comes to focusing on features that people actually want out of Swift.

A lot of effort has gone into being able to use Swift with existing Obj-C libraries - I sincerely hope they'll at some point say 'no more interop, only Swift, and by the way we've rewritten the UI libraries to use generics, so that you can do more than cute generic demos in your code.'

[0] https://genius.com/Soroush-khanlou-metaprogramming-isnt-a-sc...

   currently has no meta-programming features, in the interest of performance

This is a false dichotomy.

You're right, I'll edit that. Some meta-programming features do require sacrifices in performance, but not in the case of Codable.

And some can increase performance. Thanks for thinking about this though, it's one of the things I appreciate about this place.

IIRC they were already doing a sweep over the UI libraries to make them more Swift-idiomatic, but probably (like you say) while retaining the obj-c interface. They probably could make an extension or aliases to the UI libraries only visible to Swift though, translating down to regular obj-c compatible calls.

They've done an excellent job of going as far as you can, without re-writing parts of the code to not be backwards compatible.

My personal desire is to see a backwards incompatible UI layer, that makes generics usable.

As a simple example - you currently can't have a UITableViewCell<YourModel>, which's the most obvious and proper use of generics for UI logic.

So as it stands, all this work has gone into mixing polymorphism and subclassing, and yet it doesn't actually get used a whole lot, because of the existing libraries having been written when generics were not around.

Equatable and Hashable also have some "magic", currently only for enums without associated values. Recently this was generalized to enums where all associated values are themselves Equatable and Hashable, as well as structs where all fields are Equatable and Hashable. This is not implemented in Swift 4, but an implementation was recently added to the master branch. You can read the details here: https://github.com/apple/swift-evolution/blob/master/proposa...

Finally, gson / json.net for swift. Before this, every json static schema type must use generator or do manually