> On Mar 17, 2017, at 4:05 PM, Matthew Johnson <[email protected]> wrote:
>
>
>
> Sent from my iPad
>
> On Mar 17, 2017, at 5:38 PM, Joe Groff via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
>
>>
>>> On Mar 17, 2017, at 12:34 PM, David Hart via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> Sent off-list by mistake:
>>>
>>> Nice proposal. I have a few comments inline:
>>>
>>>> On 17 Mar 2017, at 18:04, 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:
>>>>
>>>> Many thanks,
>>>> -Michael
>>>>
>>>> Smart KeyPaths: Better Key-Value Coding for Swift
>>>> Proposal: SE-NNNN
>>>> Authors: David Smith <https://github.com/Catfish-Man>, Michael LeHew
>>>> <https://github.com/mlehew>, Joe Groff <https://github.com/jckarter>
>>>> Review Manager: TBD
>>>> Status: Awaiting Review
>>>> Associated PRs:
>>>> #644 <https://github.com/apple/swift-evolution/pull/644>
>>>> Introduction
>>>> We propose a family of concrete Key Path types that represent uninvoked
>>>> references to properties that can be composed to form paths through many
>>>> values and directly get/set their underlying values.
>>>>
>>>> Motivation
>>>> We Can Do Better than String
>>>>
>>>> On Darwin platforms Swift's existing #keyPath() syntax provides a
>>>> convenient way to safely refer to properties. Unfortunately, once
>>>> validated, the expression becomes a String which has a number of important
>>>> limitations:
>>>>
>>>> Loss of type information (requiring awkward Any APIs)
>>>> Unnecessarily slow to parse
>>>> Only applicable to NSObjects
>>>> Limited to Darwin platforms
>>>> Use/Mention Distinctions
>>>>
>>>> While methods can be referred to without invoking them (let x = foo.bar
>>>> instead of let x = foo.bar()), this is not currently possible for
>>>> properties and subscripts.
>>>>
>>>> Making indirect references to a properties' concrete types also lets us
>>>> expose metadata about the property, and in the future additional behaviors.
>>>>
>>> What metadata is attached? How is it accessed? What future features are you
>>> thinking about?
>>
>> To begin with, you'd have limited ability to stringify a key path.
>> Eventually we'd like to support other reflectiony things, including:
>>
>> - Asking for the primary key paths a type supports
>> - Asking for a key by name or index
>> - Breaking a key path down by components
>>
>> I also see key path objects as a good way of eventually addressing some of
>> the design problems we ran up against with property behaviors
>> (https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md
>>
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md>
>> from last year), including the problem of what exactly a property behavior
>> declaration *is* (a type? a protocol? a function-like thing? something
>> completely new?), and the problem of handling "out-of-band" operations on a
>> property beyond getting and setting, such as clearing a cached lazy value,
>> registering for notifications on an observable property, and so on. I think
>> it would be natural to express property behaviors as a user-defined key path
>> type; the key path type can provide the get/set logic for the property as
>> well as any other interesting operations the property supports. This answers
>> the questions of both what behaviors look like (they're just types that
>> conform to KeyPath) and how they extend properties with new actions (they're
>> just methods of the key path value) fairly nicely.
>
> Very interesting! This sounds like it would enable a very nice design in a
> project I'm working on right now. I'm looking forward to seeing this take
> shape in the future.
>
> It sounds like it wouldn't solve one use case I was hoping property behaviors
> might solve though. Sometimes we have a property that we would like to make
> a constant but cont because we can't set it until phase 2. I would really
> like to have some notion of a "phase 2 initialized constant" which would
> provide a much stronger guarantee than IUO does. There would be a very small
> window where a trap is possible between phase 1 and when it is set in phase
> 2. It would probably make more sense to actually think of this as phase 1.5
> where all of these properties must be initialized to a non-nil value, but
> self can be used in the initializing expressions.
I think that kind of use case can be handled even by the previous property
behaviors proposal, by having a behavior that presents a non-optional property
that only allows initialization by being set once, and traps if gotten before
being initialized.
-Joe
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
