WIP [ConstraintSystem] Ability to treat key path literal syntax as function type (Root) -> Value.

[gregomni]

A WIP because I haven't added tests yet. Allows coercion from KeyPath to function type in any context that expects a (Root) -> Value function type, and allows for the constraint system to figure out the desired KeyPath type from the function type for incomplete key types (e.g. constructions like \.foo where the root is unspecified).

Just creates an implicit auto closure to perform the key path application expr to { $0[keyPath: expr] }. Generated SIL is identical except for the closure name.

This is the potential feature as discussed in quite a few sorting/mapping threads on evolution, and most specifically here: https://forums.swift.org/t/key-path-getter-promotion/11185/4

[gregomni]

@swift-ci Please smoke test.

[jckarter]

I would rather we didn't add any more implicit conversions, and instead looked into generalizing the literal syntax to work in function contexts.

[gregomni]

I would rather we didn't add any more implicit conversions, and instead looked into generalizing the literal syntax to work in function contexts.

Can you go into why that would be preferable? Are there other types that would conform to ExpressibleByKeyPathLiteral? (Seems just as good to extend KeyPath instead of whatever other type you'd want to conform, and we don't really have a convenient way to hang ExpressibleByKeyPathLiteral onto function types so we'd end up with most of this similar code in the constraint system to decide to use it.) I think the main usability issue is just the distinction between a nominal type and a function type, and as long as you have easy access to referring to both, you've covered pretty much all the bases.

And you'd be removing conveniences for non-literals like

func keyMap<T, U>(_ array: [T], key: KeyPath<T, U>) -> [U] {
    return array.map(key)
}

... which granted, by itself is not terribly compelling, but it seems an odd thing to want to limit.

[jckarter]

Implicit conversions impact the entire type system, and we've set up an expectation that they hold for dynamic casts too, complicating the runtime implementation as well. Key paths and functions also currently have non-overlapping capabilities; key paths have to refer to specific declarations and subscripts/methods with hashable arguments in order to provide equality, but functions generally don't need to be equatable, so literal references in function context could be less constrained. As for whether other things could be ExpressibleByKeyPathLiteral, that doesn't seem completely out of the question.

For the general case of non-literal key paths, it doesn't seem terribly onerous to put a get method on KeyPath and use that.

[gregomni]

I find the runtime expectation argument fairly convincing. How about a compromise: I think that removing the KeyPathToFunction coercion restriction, but keeping the simplifyKeyPathConstraint changes and moving the autoclosure-ing out of coerceToType and putting it directly into visitKeyPathExpr in CSApply will have the effect you're aiming at -- KeyPathExpr then effectively becomes the literal form that is usable as a function type, but there isn't any general type coercion. But also, there'd still be no ExpressibleBy... support.

[gregomni]

Latest commit is what it would look like with KeyPathExpr being effectively a literal which can be either KeyPath<R,V> or (R)->V.

Results in:

struct Person {
    var address: Address
}
struct Address {
    var street: String
}
func f1(_ ps: [Person]) -> [String] {
    return ps.map(\.address.street) // compiles, runs
}
func f2(_ ps: [Person]) -> [String] {
    return ps.map(\Person.address.street) // compiles, runs
}

func f3(_ ps: [Person]) -> [String] {
    let kp = \Person.address.street
    return ps.map(kp) // cannot convert value of type 'WritableKeyPath<Person, String>' to expected argument type '(Person) throws -> String'
}

[davedelong]

func f2(_ ps: [Person]) -> [String] {
    return ps.map(\Person.address.street) // compiles, runs
}

func f3(_ ps: [Person]) -> [String] {
    let kp = \Person.address.street
    return ps.map(kp) // cannot convert value of type 'WritableKeyPath<Person, String>' to expected argument type '(Person) throws -> String'
}

I think the distinction here is too fine. This would totally confuse people. It confuses me.

[jckarter]

Not that it's an argument for or against, but this is the same situation you get with other literals:

func foo(x: UInt8)

foo(x: 0) // ok

let y = 0 // implicitly Int
foo(x: y) // type mismatch

[davedelong]

Not that it's an argument for or against, but this is the same situation you get with other literals:

func foo(x: UInt8)

foo(x: 0) // ok

let y = 0 // implicitly Int
foo(x: y) // type mismatch

Eh, it's not really the same. I can make that work by changing the IntegerLiteralType. Would I be able to do something analogous here?

[jckarter]

@gregomni Thanks for prototyping this! If we were going to go in this direction for real, I think it'd be better to handle this earlier in the pipeline. Whereas, for key path literals that become KeyPaths, we have to resolve the components in a specific way in order to validate the components, collect hashing conformances, etc., none of that is really relevant to a key path literal in function context. In such a context, I think we'd want to take the parsed expr-postfix production as is and wrap it in a closure early, turning \T.<postfix-expression> into { $0.<postfix-expressions> }. This should make it possible for key path literals in function type context to also reference methods, which key paths currently don't allow, as well as subscripts with non-hashable indexes.

[jckarter]

@davedelong To me, it makes sense to eventually turn this into a new literal type with an ExpressibleByKeyPathLiteral protocol that user-defined types can also conform to. If we do that, then I think it'd make sense to allow the KeyPathLiteralType to be contextually overridden the same way IntegerLiteralType can.

[gregomni]

@davedelong You can explicitly specify the type, just like in the UInt case, and then it compiles correctly:

func f4(_ ps: [Person]) -> [String] {
    let kp: (Person) -> String = \Person.address.street
    return ps.map(kp) 
}

[gregomni]

@jckarter I think that making the key path syntax sometimes have different semantics from key path application is asking for trouble, both coder expectation-wise, and also compiler maintenance-wise down the road. I can see how it'd be appealing to do as you suggest, but I think it'd be much better to implement support for methods and non-hashable subscripts in key path application instead.

[jckarter]

The constraints on literals in KeyPath context make sense given the requirements of KeyPath, but if we're generalizing this to eventually be a general "unapplied declaration reference" literal syntax, then those constraints don't make sense to apply unilaterally except that historically KeyPath happened to be the first client of this syntax. By analogy to other literals, you can't use a negative integer literal to initialize an unsigned type, for instance.

[gregomni]

I'm hesitant about premature generalization. It feels to me like we have a nominal form and a functional form of lensing (and so maybe the next step is also allowing (inout Root, Value) -> Void for writable key paths) rather than a general reference literal syntax. I'd greatly prefer to have a real life scenario with a distinct third type that wants to be initialized from a key path literal before I would go down the road of deciding which parts are shared by the generalization and which parts differ between the examples.

[natecook1000]

it'd make sense to allow the KeyPathLiteralType to be contextually overridden the same way IntegerLiteralType can.

@jckarter A stumbling block I see with this is that we don't have a nominal type to give to KeyPathLiteralType if we want the default to be a function type rather than KeyPath. Is the idea that KeyPathLiteralType would be a generic type alias, so that one could write either of these lines?

typealias KeyPathLiteralType<T, U> = (T) -> U
typealias KeyPathLiteralType<T, U> = KeyPath<T, U>

[jckarter]

Yeah, that's what I had in mind. At the time we implemented user-defined literals, we didn't have generic typealiases, so ArrayLiteralType and DictionaryLiteralType were never implemented, but we really ought to go back and implement those now too.

[beccadax]

@swift-ci please smoke test

[airspeedswift]

Hi @gregomni could you rebase your PR? Then we could produce a toolchain for people to try out as part of the review.

[beccadax]

@airspeedswift @gregomni I actually just finished squashing, rebasing, and fixing a bug in this PR in #23435. I'm running smoke tests on it now; I'll see if I can get source compatibility and compiler performance tests next.

[rjmccall]

Building an anonymous closure that just applies the key path components is, unfortunately, the wrong semantics for this; to be consistent with the normal semantics for key path evaluation, you need any subscript indices to be evaluated and captured at the time of creating the function.

[gregomni]

Closing in favor of #23435