> On Mar 17, 2017, at 10:04 AM, Michael LeHew via swift-evolution
> <[email protected]> wrote:
>
> Hi friendly swift-evolution folks,
>
> The Foundation and Swift team would like for you to consider the following
> proposal:
The Swift core team discussed this proposal draft and had a little bit of
pre-review feedback.
> Access and Mutation Through KeyPaths
> To get or set values for a given root and key path we effectively add the
> following subscripts to all Swift types.
>
> Swift
> extension Any {
> subscript(path: AnyKeyPath) -> Any? { get }
> subscript<Root: Self>(path: PartialKeyPath<Root>) -> Any { get }
> subscript<Root: Self, Value>(path: KeyPath<Root, Value>) -> Value { get }
> subscript<Root: Self, Value>(path: WritableKeyPath<Root, Value>) -> Value
> { set, get }
> }
Swift doesn’t currently have the ability to extend Any, so this is (currently)
pseudocode for compiler magic that one day we might be able to place.
Additionally, the “Root: Self” constraint isn’t something we support in the
generics system. A small note indicating that this is pseudo-code meant to get
the point across (rather than real code to drop into the standard
library/Foundation) would be appreciated.
More importantly, this adds an unlabeled subscript to every type, which raises
concerns about introducing ambiguities—even if not hard ambiguities that
prevent code from compiling (e.g., from a Dictionary<AnyKeyPath, …>)---they can
still show up in code completion, diagnostics, etc.
The core team would prefer that this subscript distinguish itself more, e.g.,
by labeling the first parameter “keyPath” (or some better name, if there is
one). Syntactically, that would look like:
person[keyPath: theKeyPathIHave]
> Referencing Key Paths
>
> Forming a KeyPath borrows from the same syntax used to reference methods and
> initializers,Type.instanceMethod only now working for properties and
> collections. Optionals are handled via optional-chaining. Multiply dotted
> expressions are allowed as well, and work just as if they were composed via
> the appending methods on KeyPath.
>
The core team was concerned about the use of the Type.instanceProperty syntax
for a few reasons:
* It doesn’t work for forming keypaths to class/static properties (or
is ambiguous with the existing meaning(, so we would need another syntax to
deal with that case
* It’s quite subtle, even more so that the existing Type.instanceMethod
syntax for currying instance methods
> There is no change or interaction with the #keyPath() syntax introduced in
> Swift 3.
>
The core team felt that extending the #keyPath syntax was a better syntactic
direction to produce key-paths.
- Doug
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
