[swift-evolution] [Review] SE-0166: Swift Archival & Serialization

[Karl Wagner]

> On 13 Apr 2017, at 06:20, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Apr 12, 2017, at 2:12 PM, Zach Waldowski via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> I want to disagree with this is strongly as possible lest it influence
>> the proposal in any way whatsoever. Just because you can solve something
>> through reflection doesn't mean you should.
> 
> 
> Cosigned. Reflection is really cool, but it's generally going to be the least-efficient, most-buggy possible way to implement a given feature. There's something to be said for just...writing some code. Especially when the computer is writing it for you.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

The computer writing it for you is good, but the compiler writing it for you is bad. For one thing, it’s less easy to debug source code that isn’t written anywhere.

I continue to think this proposal would be better with some kind of attribute (“annotation” in javaspeak) to allow more principled code-generation. Or a "property behaviour”, if that’s intended to do the same thing.

It could possibly be built-in (like @NSManaged, @objc, lazy, etc):

struct MyThing: Codable {
    @coded let id: Int64
    let name: String
}

This proposal is optimised for POD types where everything is serialised and there is no danger of leaking private, disposable or otherwise non-persistable details. 
Once you want to leave a field out, you’re back to the same-old boilerplate that every other serialisation framework faces. An attribute would help with that.

That’s just one of the issues with this proposal. Having some way to customise the key name is another; you could imagine the attribute could take a parameter - e.g. @coded(“thing_id”).

I’d certainly consider supporting a better proposal, but this one is too narrow in capabilities and imagination IMO.

- Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170415/146a26cd/attachment.html>