Thanks for the feedback everyone! We have pushed a changed a bit ago to the proposal reflecting these desires.
https://github.com/apple/swift-evolution/pull/644/files -Michael > On Mar 29, 2017, at 2:49 PM, Douglas Gregor <[email protected]> wrote: > > >> On Mar 17, 2017, at 10:04 AM, 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: > > > 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
