4 ms·
The one thing I don't love about Swift's Codable is the lack of customizability in the "magic" part: the part where the compiler generates the Encodable/Decodab
by conradev 8y ago
The one thing I don't love about Swift's Codable is the lack of customizability in the "magic" part: the part where the compiler generates the Encodable/Decodable implementations. Most notably, the compiler can't generate implementations for enums. The only thing that Swift supports customizing without fully implementing the methods for Encodable and Decodable is the name of the keys, using a custom CodingKeys type.
Serde, an equivalent third-party crate in Rust, supports a lot of customization which I find invaluable. It can (de)serialize values like this with ease:
{"type": "location", "value": {"latitude": 0, "longitude": 0}}
in a very small amount of code:
#[derive(Serialize, Deserialize)]
#[serde(tag = "type", content = "value")]
#[serde(rename_all = "lowercase")]
enum Value {
Location { latitude: f64, longitude: f64 },
String(String),
...
}
Serde also supports customizing serialization on a per-field basis without having to implement the entire protocol, which is nice:
#[derive(Deserialize, Serialize)]
struct Record {
#[serde(with = "chrono::serde::ts_seconds")]
updated: DateTime<Utc>
}
I really hope that Swift has better ways (like the above) to customize Codable in the future. I find myself implementing the protocol myself in 90% of cases, whereas I very rarely have to do that for Serde.
- maxdesiatov 8y agoThe main reason for that is lack of hygienic macros in Swift. Currently you can use code generation tools like Sourcery and SwiftGen, but I expect 1st-class meta-programming support to come after Swift 5.0 release. After ABI stability I imagine macros are pretty high on the priority list of the core team.
- conradev 8y agoThey might also go in the opposite direction and add runtime APIs to construct types dynamically. Various initiatives (like the Python interop for TensorFlow) are pulling Swift in that direction: https://github.com/apple/swift-evolution/blob/master/proposals/0195-dynamic-member-lookup.md https://github.com/apple/swift-evolution/blob/master/proposa... https://github.com/apple/swift-evolution/blob/master/proposals/0216-dynamic-callable.md https://github.com/apple/swift-evolution/blob/master/proposa...
- slavapestov 8y agoI have a hard time envisioning full-fledged macros coming to Swift, but moving Equatable/Hashable/Codable synthesis to a library should be possible with more restricted meta-programming capabilites. See Joe Groff's talk for details: https://www.skilled.io/u/swiftsummit/swift-s-reflective-underpinnings-joe-groff https://www.skilled.io/u/swiftsummit/swift-s-reflective-unde...
- saagarjha 8y ago> I have a hard time envisioning full-fledged macros coming to Swift, but moving Equatable/Hashable/Codable synthesis to a library should be possible with more restricted meta-programming capabilites. I've heard many people on the mailing lists talk about wanting to add hygienic macros–so when you're talking about "full-fledged macros", are you talking about unhygienic or hygienic ones? > See Joe Groff's talk for details I'm actually curious how much is possible, in terms of reflection capability, both currently and in the future. How close can I get to the dynamism of say the Objective-C runtime? Can I grab a function pointer knowing its mangled name? Can I list every class in a binary by consulting the runtime metadata? Can I "swizzle"?
- slavapestov 8y ago> How close can I get to the dynamism of say the Objective-C runtime? Well, right now the compiler emits a lot of metadata that is mostly used for runtime generics, dynamic casting, and the (somewhat limited) Mirror type. But these features have enough generality that a surprising amount of stuff has to be encoded. However there’s no nice API for looking at it yet. > Can I grab a function pointer knowing its mangled name? That’s just dlsym(). > Can I list every class in a binary by consulting the runtime metadata? The metadata is there, but there’s no exposed API for doing this. > Can I "swizzle"? There’s an experimental thing for this now: https://github.com/apple/swift/pull/20333 https://github.com/apple/swift/pull/20333
- saagarjha 8y ago> > Can I grab a function pointer knowing its mangled name? > That’s just dlsym(). Sorry, I should have been more clear: can I grab a function pointer to an unexported function? > > Can I "swizzle"? > There’s an experimental thing for this now: https://github.com/apple/swift/pull/20333 https://github.com/apple/swift/pull/20333 This is interesting; I haven't been really been following the lists recently but I took the time to read the linked thread and the pull request. While the functionality contained in the pull request is interesting, it's not quite the same as swizzling since it's done unconditionally at load time rather than runtime (so it's much more similar to DYLD_INTERPOSE in that sense). While this covers many of the cases when swizzling is necessary, it leaves out a rather important one where the correct method override is selected at runtime, generally conditionally. Also, as a sidenote, it seems that there is some sort of motivation to have compiler type checks for the replacement, i.e. @_dynamicReplacement(for: bar())–how will this actually work in practice? If I compile a bundle without access to the source of the application I'm going to be loaded into, how would bar() be accessible to the compiler at all?
- wild_preference 8y agoSerde offers more out of the box functionality with its annotations, but it's also bit uglier than Swift's Codable when you do need to implement it yourself. If it wasn't for a blog post that gave some simple examples, I couldn't even figure it out myself. Possibly not fair to compare them this way, though. No clue what the trade-offs are.
- conradev 8y agoThat's very fair criticism. Implementing custom serde serializers is painful, but thankfully I only have to do it in rare circumstances.