Hi everyone. The review for SE-0438, Metatype keypaths ran from May 30 through June 13, 2024. The Language Steering Group has decided to accept the proposal, with the elaboration of the implications for adoption offered by the proposal authors.
As the edited proposal notes, forming keypath references to static members from other modules requires those modules to be rebuilt, so that their binary products can publish new property descriptor symbols, even though the resulting program is still back deployable. This is because the linker on some platforms requires weak-imported symbols to have a definition at link time. The Language Steering Group would still like to see further investigation into whether it is possible to implement extensions to key paths without requiring new property descriptor definitions to exist at link time, whether by improvements to linkers on supported platforms or by changes to the implementation strategy. Doing so would benefit future extensions to what storage definitions key paths can reference and could also provide a small code size benefit for the existing key path implementation. As a quality of implementation concern, however, that investigation does not need to block our acceptance of the proposal.
Reviewers also raised the question of whether \TypeName.staticMember should be allowed to refer to a static member key path when it's unambiguous to do so. In the rest of the language, Swift keeps static members separately namespaced from instances, requiring TypeName.staticMember or type(of: instance).staticMember to refer to a static or class property relative to an instance, and we think that metatype keypaths should maintain that separation. The authors' implementation detects this situation and diagnoses it with a fix-it, which the Language Steering Group believes is sufficient.
Thank you to everyone who participated in the review!