[swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Itai Ferber]

Thanks for the comments, David.
I responded to #2 in a separate email, but wanted to get back to 
responding to #1.

In implementing this, I have had the same thoughts. Ideally, one day, we 
would be able to migrate the implementation of this away from the 
compiler to public API (through reflection, property behaviors, or 
similar). If the compiler offers external features that would allow us 
to do everything that we want, I would be more than happy to move the 
implementation from inside the compiler to outside of it.

On 16 Mar 2017, at 0:09, David Hart wrote:

> First of all, great proposal :D
>
> Brent, earlier in the thread makes a lot of good points. But I’d 
> still like to discuss two subjects:
>
> 1) What makes the proposal really stand on its feet compared to 
> third-party libraries is the compiler generation magic. I feel divided 
> about it. On one hand, this is the only solution today to have this 
> level of type and key safety. But on another hand, I have the 
> impression that future versions of Swift (with more reflection, 
> property behaviours, lenses, etc…) would dramatically affect how 
> this subject is treated and implemented. Are you worried that we are 
> asking the compiler to do work which might be un-necessary in the 
> future? That this topic would be better expressed with more powerful 
> language features? Any plans to migrate for this API to smoothly 
> migrate to those features in the future?
>
> 2) Libraries like Marshal (https://github.com/utahiosmac/Marshal 
> <https://github.com/utahiosmac/Marshal>) and Unbox 
> (https://github.com/JohnSundell/Unbox 
> <https://github.com/JohnSundell/Unbox>) don’t require the decoding 
> functions to provide the type: those functions are generic on the 
> return turn and it’s automatically inferred:
>
> func decode<T>(key: Key) -> T
>
> self.stringProperty = decode(key: .stringProperty) // correct 
> specialisation of the generic function chosen by the compiler
>
> Is there a reason the proposal did not choose this solution? Its quite 
> sweet.
>
>> Swift Archival & Serialization
>> Proposal: SE-NNNN <https://github.com/apple/swift-evolution/pull/639>
>> Author(s): Itai Ferber <https://github.com/itaiferber>, Michael LeHew 
>> <https://github.com/mlehew>, Tony Parker <https://github.com/parkera>
>> Review Manager: TBD
>> Status: Awaiting review
>> Associated PRs:
>> #8124 <https://github.com/apple/swift/pull/8124>
>> #8125 <https://github.com/apple/swift/pull/8125>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170316/0080d790/attachment.html>