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