Key paths could be made to work by implementing the protocol in terms of retrieving key paths instead:
protocol SupplementalKeyPathDispatching { associatedType KP: PartialKeyPath<Self> static func supplementalKeyPath(for name: String) -> KP } and in your implementation of PyVal: extension PyVal: SupplementalKeyPathDispatching { static func supplementalKeyPath(for name: String) -> KeyPath<PyVal, PyVal> { return \PyVal[dynamicMember: name] } } The compiler then implements two transforms: \PyVal.add_trick // becomes: PyVal.supplementalKeyPath(for: "add_trick") // returns key path \PyVal[dynamicMember: name] and: let Dog = Python.import(“DogModule.Dog") let dog = Dog("Briana") dog.add_trick("snore") // becomes: dog[keyPath: \PyVal.add_trick]("snore") // or fully expanded: dog[keyPath: PyVal.supplementalKeypath(for: "add_trick")]("snore") // calls dog[dynamicMember: name] You now have one more level of indirection which allows key paths. There's no compile time checking however: all imaginable key paths will work. > Le 16 nov. 2017 à 1:00, Brent Royal-Gordon via swift-evolution > <swift-evolution@swift.org> a écrit : > > * Actually, for that matter, let's talk about key paths. In principle, you > can already think of member lookup in Swift—or at least property and > subscript lookup—as though it always worked by constructing a key path and > using `subscript(keyPath:)` to access it. Is there some way we could model > this feature as extending the set of keys available on a given type—perhaps > in a way that allowed compile-time-limited and strongly-typed sets of keys, > like I mention with the `UIAppearance` example, in addition to the > open-ended, type-erased sets you need—and then looking things up by key path? > (Sorry if this is a little vague—I know very little about how key paths are > implemented.) > -- Michel Fortin https://michelf.ca
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution