> On Mar 17, 2017, at 3:17 PM, Michael LeHew via swift-evolution
> <[email protected]> wrote:
>
>>
>> On Mar 17, 2017, at 3:08 PM, Matthew Johnson <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>>
>>> On Mar 17, 2017, at 12:04 PM, Michael LeHew via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> Hi friendly swift-evolution folks,
>>>
>>> The Foundation and Swift team would like for you to consider the following
>>> proposal:
>>
>> This proposal is really incredible! It is an invaluable addition to the
>> language - far better than simple first-class properties. I really can’t
>> wait to see it implemented! The design looks very solid. I’m especially
>> happy to see that a path to eventually get away from using classes has
>> already been identified and planned for.
>>
>> Thank you so much for bringing this forward in Swift 4. It is a wonderful
>> (and rather unexpected) surprise!
>>
>> Seeing this makes me *really* wish we had a way to get at a collection of
>> `PartialKeyPath<Self>` for all the (visible) properties of a type. I guess
>> the visible part of that makes it tricky. We can always work around it in
>> the meantime.
>
> We had discussed that a future application where KeyPath's would make a lot
> of sense is with the Mirror API. Of course in the interest of the finiteness
> of time, we aren't pursuing that right now.
>
> One thing that gets interesting with the scope-restricted visibility of
> KeyPaths, is what happens if an fileprivate KeyPath gets leaked out of the
> file? That's a scary/maybe useful thing? But a complication that emerges
> pretty quick and thus another reason not to pursue that just now.
I think that's fine. It's no different from passing out a private function as a
closure value, or passing out a value of a private type as a protocol
existential or public base class instance.
-Joe
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
