That section does cover both, though perhaps so obliquely it was easy to miss. In fact it directly mentions your idea of adding an inout param for mutating methods:
Key paths for mutating methods might induce an
inoutparam for self:let appender: (inout Array<Int>, Int) -> Void = \Array.append appender(primes, 7)
…and it draws exactly the contrast you’re talking about:
…but that idea only makes sense when using key path literals as a convenience to form closures; it quickly breaks down when using actual key path values as subscripts:
var mersennes = [0, 1, 3] primes[keyPath: \.append](mersennes, 7) // Which is mutated: mersennes or primes?
…arguing that we’re better off considering mutating methods as a separate design unit (which I’m all in favor of doing, should this proposal pass):
This line of reasoning suggests that mutating methods are best left for a follow-up proposal:
- If they are in fact limited to key path literals converted to closures, then they are both outside the scope of this proposal and not in conflict with it.
- If we seek a broader solution, it would need to be consistent with unbound methods as well, and thus (as in the previous section) this proposal is only uniformly respecting an existing problem, not introducing a new one.
(And just to be crystal clear: I'm all for another proposal to meet the need you're talking about; it seems compelling.)