SE-0479: Method and Initializer Key Paths

Evolution Proposal Reviews
10

-1 from me.

Lack of support for argument labels, mutating and effectful functions makes me conclude that key paths are a wrong tool for the job, at least for the @dynamicMemberLookup.

I would appreciate proposal text summarising advantages over unapplied, partially applied and applied methods. Going through entire pitch thread complicates review process.

Method keypaths are Hashable, which is indeed an improvement compared to method types.

Pitch mentions that keypaths have metadata, but aside from Hashable conformance there is no public API to use this metadata. (There is SPI _kvcKeyPathString available only for ObjC properties).

Handling properties and methods in a unified manner can be beneficial for some use cases, but can be limiting for use cases that actually want to do something with the arguments.

Using method keypaths with @dynamicMemberLookup does not allow to inspect or modify values of arguments and the result.

IIUC, in this example:

@dynamicMemberLookup
struct DynamicKeyPathWrapper<Root> {
    var root: Root

    subscript<Member>(dynamicMember keyPath: KeyPath<Root, Member>) -> Member {
        root[keyPath: keyPath]
    }
}

let dynamicCalculator = DynamicKeyPathWrapper(root: Calculator())
_ = dynamicCalculator.subtract(10)

Member is (Int) -> Int, so the value 10 is not even stored inside the keypath.

Unless I'm missing something, I don't see how this feature would enable building Mockable<T> or TransitionParticipant from the usage examples given in the pitch.

5 Likes