[swift-evolution] Swift's reflection

[Jonathan Hull]

> On Mar 17, 2017, at 2:43 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Mar 17, 2017, at 3:42 PM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> I hope that Mirror will ultimately be superseded by key paths:
>> 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033998.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033998.html>
>> 
>> Key paths address the mutability limitations of mirror, and give you the ability to work with arbitrary values in a dictionary-like way that Mirror does without an intermediary type. While the initial key path proposal lacks the dynamic discovery of key paths by name/index/etc., that would be a natural future direction to go in. Being able to build or query key paths dynamically would also solve other problems with Mirror, such as not being able to discover the structure of a value without an instance of the value.
> 
> This all sounds so incredible!  I’m really looking forward to dynamic discovery and manipulation of key paths, especially without needing an instance of the type to do it.  It can’t come soon enough - I already have a project where it could come in very handy!

+1.  I have a project right now that could use this tomorrow (and another one which is on hold until something like this becomes available).

The project I am working on now would use it for auto-generating user interfaces (right now I need to use getter & setter closures). The one on hold would use it for hooking together parts of the event system (basically I need KVO, but made it using Protocol-oriented design… which was great until I realized I needed KVO).

Thanks,
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170320/df742edc/attachment.html>