Comment by Frederick Kellison-Linn (JIRA)

cc @LucianoPAlmeida seems potentially related to SR-13079

Yeah, they are related in the sense of key path root optional mismatch
I'm thinking on how to improve this ... it could probably be something like `cannot convert key path root type 'String' to specified type 'String?'`, with a fix-it to make it optional to match the contextual type and unwrap to access unwrapped `String` member: `let _: KeyPath<String?, Int> = String?.!.count`, that for sure will be a better diagnostic.

Comment by Frederick Kellison-Linn (JIRA)

Yeah even without the fix-it that would be a much better diagnostic.

I believe this exhibits a similar issue:

class Base {}
class Derived: Base {
    var x: Int = 0
}

let _: KeyPath<Base, Int> = \Derived.x // ERROR: value of type 'Base' has no member 'x'

Due to how we generate constraints for key path expressions:

        // Allow \Derived.property to be inferred as \Base.property to
        // simulate a sort of covariant conversion from
        // KeyPath<Derived, T> to KeyPath<Base, T>.
        CS.addConstraint(ConstraintKind::Subtype, rootObjectTy, root, locator);

Ah that is interesting, I was more focused on optionality mismatches and actually don't remember having seeing this issue, does this constraint is in-place to allow code like this

class Base {
  var x: Int = 0
}
class Derived: Base {}

let _: KeyPath<Base, Int> = \Derived.x // Ok

? Maybe I didn't understand it correctly ...

Comment by Frederick Kellison-Linn (JIRA)

I believe that's the idea, yeah. I haven't dug into the history to be sure though. I stumbled across this behavior when I thought I had broken something during my prototype for function-function conversions with keypath literals, but then I realized this behavior exists for 'normal' key paths as well.