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>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
