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

David Sweeris davesweeris at mac.com
Sat Apr 15 17:32:02 CDT 2017

> On Apr 15, 2017, at 9:40 AM, Karl Wagner via swift-evolution <swift-evolution at swift.org> wrote:
>> On 13 Apr 2017, at 06:20, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org <mailto: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.
> 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.

Depends on exactly what you mean by “isn’t written anywhere”... Xcode can show what a C-family file looks like post-preprocessing (although I don’t think it lets you set breakpoints or anything, so it’s only half a solution in terms of debugging). I haven’t used other IDEs enough to know if that’s a common feature. Anyway, I’m not sure that’s a road we should or even can go down, but it’s not entirely without precedent.

- Dave Sweeris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170415/4b7a8f0d/attachment.html>

More information about the swift-evolution mailing list