> On Mar 17, 2017, at 4:25 PM, Matthew Johnson <[email protected]> wrote:
>
>
>
> Sent from my iPhone
>
> On Mar 17, 2017, at 6:09 PM, Joe Groff <[email protected]
> <mailto:[email protected]>> wrote:
>
>>
>>> On Mar 17, 2017, at 4:05 PM, Matthew Johnson <[email protected]
>>> <mailto:[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.
>
> Didn't it require trapping if set more than once? And it didn't offer a way
> to require initialization during phase 2 did it?
Yes, but perfectly closing those holes requires a much more complex type system
than we have. Perfect is the enemy of good, and I think trapping on misuse gets
you the lion's share of the benefit, and would still be a massive improvement
over IUO.
-Joe
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
