Great work! Thanks for pushing this forward. These new KeyPaths abilities are ultimately valuable for composition and as alternative to inheritance.
Some points to the design:
– I personally would prefer to treat S()[keyPath: kp] like a reference to function rather than direct call to it. So function call will be done as S()[keyPath: kp](). This way, passing function arguments will be done as S()[keyPath: kp](0, 1.0, "string") – this seems natural and similar to passing args to closure, but the problem is that normal KeyPaths return property values but not reference to property (technically KeyPath itself can be treated as reference to concrete property)
So Another one idea is to introduce a [funcPath:] instead of [keyPath]. This syntactically reflects better with what thing we are dealing and its behaviour.
Exposing so much new Path-Types is felt like a misdirection at a first look. There also several proposals under active review, e.g. isolation(any) and RBA that also affect type system and subtyping specifically, also we have typed throws where throws(Never) is the same as no throw . I assume in reality even more Path-Types is needed after those proposals will be accepted.
I suppose the help of Type system engineers is needed here.