SE-0249: Key Path Expressions as Functions

[masters3d]

• What is your evaluation of the proposal?
  I think this would cause confusion unless it also address tuples. If that is the case then that should cut the surface area of tuples which can help us get closer a 0110 being implemented.
  https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md

• Is the problem being addressed significant enough to warrant a change to Swift?
  Not by itself I am afraid. If I am able to use KeyPath notation in this way I would be confused by it as new user.

Look at the reasoning for reverting 0110 it was mostly due to closures which this proposal should address.

https://lists.swift.org/pipermail/swift-evolution-announce/2017-June/000386.html

Revert "[Sema] ban multi-arguments to tuple coercion" (#3922)

Edit:

  let pairs = [(1, "A"), (2, "B")]
  print(pairs.map { $0.0 })

I am saying that this is a great feature but it needs to include tupples KeyPath otherwise it will cause confusion.

KeyPaths, Tuples and Swift 5

I think this would be a great starter project. The runtime ABI for keypaths should not need any modification to handle tuple components, so there's no rush to implement this. There's an ABI document that describes the layout of key path objects; the details are somewhat out of date, but the high level structure is the same: A tuple component ought to be compiled to the same runtime representation as a "struct stored property" component, with the in-memory offset of the tuple element from the …