<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Pitiphong,<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 13, 2017, at 12:37 AM, Pitiphong Phongpattranont via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi swift-evolution,</div><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">Here’re my feedbacks</div><div class=""><br class=""></div><div class="">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 <a href="http://bugs.swift.org/" class="">bugs.swift.org</a></div><div class="">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</div></div></div></blockquote><div><br class=""></div>Would you be willing to share an example of what your JSON looks like and what your resulting DateComponents struct looks like here?</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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.</div></div></div></blockquote><div><br class=""></div><div>Yah, it’s certainly reasonable to adopt Decodable on an enum with an associated value, but I’m not sure if we should try to expand the automatic synthesis to handle this case or just ask these kinds of types to implement Decodable manually. We’re hoping that the synthesis covers a lot of cases, but it was a non-goal to attempt to cover 100% of the possible scenarios this way. We focused a lot on making the API usable on its own too.</div><div><br class=""></div><div>- Tony</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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.</div><div class=""><br class=""></div><div class="">Those are my feedbacks on SE-0166 and SE-0167 for now. I hope my feedbacks would help the Swift and Swift community</div><div class=""><br class=""></div><div class="">Best regards,</div><div class="">Pitiphong Phongpattranont</div><div class=""><br class=""></div>
> Hi swift-evolution,<br class="">> <br class="">> Over the course of the past few weeks, we’ve been gathering feedback<br class="">> about the outcome of<br class="">> [SE-0166](<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md</a>)<br class="">> and<br class="">> [SE-0167](<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md</a>)<br class="">> (both internally and externally), and we gathered a collection of<br class="">> updates that we’re going to introduce to the proposals and to the<br class="">> implementation.<br class="">> <br class="">> Attached is rendered HTML (I don’t want to make your mail clients<br class="">> unusable like last time!) that lays out what we’d like to do. We’re<br class="">> not looking to do a full review of these changes, but if you have<br class="">> feedback or questions, we’re happy to get responses here.<br class="">> <br class="">> Please note that some of these features have already been implemented<br class="">> (the new error types, some of the optionality changes, collection<br class="">> conformances, etc.), but we are receptive to comments on all of it. The<br class="">> existing proposals will also be updated to incorporate these updates.<br class="">> <br class="">> Thanks for all of your feedback!<br class="">> <br class="">> — Itai<br class="">> <br class="">> <br class="">><span class="Apple-converted-space"> </span>
</div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>