I’d like to ask if someone knows about the current state of affairs of the evolution of the reflection API in Swift.
I read it was (or at least used to be) in the scope of Swift 4 to improve on the current capabilities, but failed to see any proposal in that direction since then. I found this evolution post (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003401.html\) from quite a while ago, and would like to know if anything progressed since then.
As a domain specific languages designer, reflection is an essential feature for me. Unfortunately I think Swift is quite behind regarding that point. Most specifically, the inability to set properties discovered from a mirror (without resorting to the black magic of unsafe pointers) has a huge impact on the simplicity of embedded DSLs.
Adding write reflection to the existing Mirrors implementation should not be too difficult and we would accept a well-written PR that adds this capability.
Slava
···
On Mar 15, 2017, at 8:10 AM, Dimitri Racordon via swift-evolution <swift-evolution@swift.org> wrote:
Hello fellow evolutionists,
I’d like to ask if someone knows about the current state of affairs of the evolution of the reflection API in Swift.
I read it was (or at least used to be) in the scope of Swift 4 to improve on the current capabilities, but failed to see any proposal in that direction since then. I found this evolution post (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003401.html\) from quite a while ago, and would like to know if anything progressed since then.
As a domain specific languages designer, reflection is an essential feature for me. Unfortunately I think Swift is quite behind regarding that point. Most specifically, the inability to set properties discovered from a mirror (without resorting to the black magic of unsafe pointers) has a huge impact on the simplicity of embedded DSLs.
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.
-Joe
···
On Mar 16, 2017, at 2:38 PM, Slava Pestov via swift-evolution <swift-evolution@swift.org> wrote:
Adding write reflection to the existing Mirrors implementation should not be too difficult and we would accept a well-written PR that adds this capability.
Slava
On Mar 15, 2017, at 8:10 AM, Dimitri Racordon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hello fellow evolutionists,
I’d like to ask if someone knows about the current state of affairs of the evolution of the reflection API in Swift.
I read it was (or at least used to be) in the scope of Swift 4 to improve on the current capabilities, but failed to see any proposal in that direction since then. I found this evolution post (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003401.html\) from quite a while ago, and would like to know if anything progressed since then.
As a domain specific languages designer, reflection is an essential feature for me. Unfortunately I think Swift is quite behind regarding that point. Most specifically, the inability to set properties discovered from a mirror (without resorting to the black magic of unsafe pointers) has a huge impact on the simplicity of embedded DSLs.
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!
···
On Mar 17, 2017, at 3:42 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
-Joe
On Mar 16, 2017, at 2:38 PM, Slava Pestov via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Adding write reflection to the existing Mirrors implementation should not be too difficult and we would accept a well-written PR that adds this capability.
Slava
On Mar 15, 2017, at 8:10 AM, Dimitri Racordon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hello fellow evolutionists,
I’d like to ask if someone knows about the current state of affairs of the evolution of the reflection API in Swift.
I read it was (or at least used to be) in the scope of Swift 4 to improve on the current capabilities, but failed to see any proposal in that direction since then. I found this evolution post (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003401.html\) from quite a while ago, and would like to know if anything progressed since then.
As a domain specific languages designer, reflection is an essential feature for me. Unfortunately I think Swift is quite behind regarding that point. Most specifically, the inability to set properties discovered from a mirror (without resorting to the black magic of unsafe pointers) has a huge impact on the simplicity of embedded DSLs.
+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
···
On Mar 17, 2017, at 2:43 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
On Mar 17, 2017, at 3:42 PM, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I hope that Mirror will ultimately be superseded by key paths:
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!