On 30.03.2017 16:12, Matthew Johnson via swift-evolution wrote:
Sent from my iPad On Mar 30, 2017, at 12:35 AM, David Hart via swift-evolution <[email protected] <mailto:[email protected]>> wrote:Sent from my iPhone On 30 Mar 2017, at 01:13, Michael J LeHew Jr via swift-evolution <[email protected] <mailto:[email protected]>> wrote: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 -MichaelI'm not a fan of the new syntax for creating key paths. To me, it feels like they've been demoted to second class citizens of the language simply because of how more verbose it now is. The new syntax is also too confusingly similar to string key paths: I had to look closely at the code to see the difference. Is there no symbol we can use to make it ambiguous? Ideas: Person::friend.lastName Person/friend.lastName Person#friend.lastName I'm a fan of the first one as it has similarities to names pacing in C++.I'm a big fan of the last one. I argued for it earlier as the best syntax to use if we deviated from the initial proposal. I like it for several reasons: - # suggests compiler magic is at work which is the case here. - #friend.lastName works nicely as a shorthand in contexts expecting a key path with a fixed Root - # would work for unbound methods solving the no arguments case. IMO all unbound members should be accessed using the same syntax.
Strong support. IMO proposal should be currently updated to unify the syntax of unbound methods access and key path access, IMO *this* should be one of the main targets of the proposal. I.e.
var method1 = MyType#foo() // unbound method
var method2 = MyType#foo(param:) // unbound method
var keypath = MyType#person.name // keypath
Personally I think the '@' could be used also as("type AT path"):
var method = MyType@foo() // unbound method
var keypath = [email protected] // keypath
But I agree that '#' is a strong marker that we are dealing with some
compiler magic here.
- # enables the possibility of mixing property access and method calls in the path as a future enhancement The arguments supporting this approach are pretty strong to me. I agree with David that the #keyPath syntax makes it feel more like a second class citizen, not just because of the verbosity but also because it is directly borrowed from an Objective-C interop feature. This is a very powerful feature that deserves to be a first class syntactic citizen every bit as much as unbound methods do.David.On Mar 29, 2017, at 2:49 PM, Douglas Gregor <[email protected] <mailto:[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 methodsThere 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] <mailto:[email protected]> https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________ swift-evolution mailing list [email protected] <mailto:[email protected]> https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
