[swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

Elviro Rocca retired.hunter.djura at gmail.com
Thu Aug 3 02:23:41 CDT 2017


Wrapper structs FTW. I think it's a lovely pattern that's super Swifty and really should be advertised more for solving these kinds of problems. Language-level features could also be useful for making that more usable, and the discussion about "strong" typealiases seems oriented in that direction.


Elviro


> Il giorno 03 ago 2017, alle ore 08:35, David Hart via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> ha scritto:
> 
> 
>> On 3 Aug 2017, at 08:00, Slava Pestov <spestov at apple.com <mailto:spestov at apple.com>> wrote:
>> 
>> 
>> 
>>> On Aug 2, 2017, at 10:48 PM, David Hart <david at hartbit.com <mailto:david at hartbit.com>> wrote:
>>> 
>>> Somewhat related: I have a similar problem in a project where I need two different Codable conformances for a type: one for coding/decoding from/to JSON, and another one for coding/decoding from/to a database row. The keys and formatting are not identical. The only solution around that for now is separate types, which can be sub-optimal from a performance point of view.
>> Actually if the wrapper types are structs with a single field, their use should not introduce any additional overhead at runtime.
> 
> I ❤️ Swift
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>> Slava

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170803/539108aa/attachment.html>


More information about the swift-evolution mailing list