Hi swift-evolution, I have a few feedbacks on SE-0166 and SE-0167. I’m a library maintainer of a Swift library for my company. We’re a payment gateway service and have a wide range of support library in many programming languages (including Swift).
Here’re my feedbacks 1. The auto synthesized code from the Swift compiler is a great feature but I’m not sure if this is a bug. If I have a property of type Dictionary<String, Any>, the auto synthesize doesn’t work and I need to implement the init(from decoder:) method manually (with code like `metadata = try container.decodeIfPresent([String: Any].self, forKey: .metadata)`) I will report this as a bug on bugs.swift.org <http://bugs.swift.org/> 2. In JSONEncoder/Decoder, you can specify the date parsing behavior since there’re many ways to represent this. My thought is that that should apply to `DateComponents` too since there are also many ways to represent `DateComponent` e.g. the ISO8601 also has a spec for parsing the date or time which should map to `DateComponents` type in Swift. And since the DateComponents already conforms to the Decodable protocol so I cannot (and should not) override the system behavior so I need to do the decoding manually on every types that have a property of DateComponents type 3. Since Swift has an associated value enum while many others doesn’t have (including JavaScript which is the mother of JSON), I design our library to use the power of associated value enum as much as possible. This means that there are some types/properties those are built from a multiple properties of a JSON object. For example: The status property of Charge is an enum which has a associated value case for `failure` status. So in my library it is built from the `status` and `failureMessage` properties in JSON. For now there is no simple or automatic way (auto synthesized code from Swift Compiler) to do this in Decodable. I need to implement it manually on every types those have this similar properties. And TBH I still don’t have any ideas on how to design the Decodable to support this feature. Those are my feedbacks on SE-0166 and SE-0167 for now. I hope my feedbacks would help the Swift and Swift community Best regards, Pitiphong Phongpattranont > Hi swift-evolution, > > Over the course of the past few weeks, we’ve been gathering feedback > about the outcome of > [SE-0166](https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md) > and > [SE-0167](https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md) > (both internally and externally), and we gathered a collection of > updates that we’re going to introduce to the proposals and to the > implementation. > > Attached is rendered HTML (I don’t want to make your mail clients > unusable like last time!) that lays out what we’d like to do. We’re > not looking to do a full review of these changes, but if you have > feedback or questions, we’re happy to get responses here. > > Please note that some of these features have already been implemented > (the new error types, some of the optionality changes, collection > conformances, etc.), but we are receptive to comments on all of it. The > existing proposals will also be updated to incorporate these updates. > > Thanks for all of your feedback! > > — Itai > > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
