[SR-13426] Code completion inserting invalid key path code when contextual type has optional root

[LucianoPAlmeida]

Previous ID	SR-13426
Radar	None
Original Reporter	@LucianoPAlmeida
Type	Bug
Status	Closed
Resolution	Done

Attachment: Download

Environment

Xcode 12 Beta 1 Swift 5.3

Additional Detail from JIRA

Votes	0
Component/s	CodeCompletion, Compiler
Labels	Bug
Assignee	@LucianoPAlmeida
Priority	Medium

md5: a1df7824b85ed7ba81bc9ad88e92c0eb

Issue Description:

When having a contextual key path type with an optional root

struct A {
  var property: String
}
let keyPath: KeyPath<A?, String> = \.#^COMPLETION^#

Code completion gives those options

And when selecting a property, the inserted code is invalid


Because `?.property` is not acceptable since inferring key path root type as an optional is not supported. The problem is that we also cannot`.property` because it would not be able to convert the inferred non-optional root to the optional contextual root.

So I'm not sure what would be a solution to this, maybe not allow declarations of a key path with optional root...

[LucianoPAlmeida]

cc theindigamer (JIRA User) @hamishknight

[typesanitizer]

I'm not sure what this has to do with property specifically. Looks like three of the four suggestions are incorrect. Inserting either customMirror or property or unsafelyUnwrapped – all of them lead to code which doesn't compile. IMO the fix should be that code completion returns fewer options.

> maybe not allow declarations of a key path with optional root

Maybe I'm misunderstanding this suggestion but this could break existing code.

struct A {
  var property: String
}
extension Optional {
  var myString: String {get { "hi" }}
}
let keyPath: KeyPath<A?, String> = \.myString

[LucianoPAlmeida]

You right, I just didn't thought about this case.
So maybe in the key path case when the root is optional, code completion should not offer optional `Wrapped` members?

[typesanitizer]

That does sound like the right fix.

[LucianoPAlmeida]

Great, I'll assign myself and try to take a look at this

[theblixguy]

I have never seen the use of a KeyPath with optional root type, I wonder how common it is... are there any cool/useful scenarios where it would be helpful? Also, slightly off-topic but I think it would’ve been a bit nice if code completion had a feature where it would show members of the unwrapped type (A) but sort of greyed out with a hint that said “accessible if Root was A”!

[LucianoPAlmeida]

Yeah, I've also never seen it, besides this example that Varun post where the key path is used to lookup a member on Optional, I can't think of any other case since `\A?.member` and neither key path root being inferred as Option are not allowed.
Not sure how often people use this though, I would guess that is very unlikely seem a real use of it.

[typesanitizer]

In theory, you could build a Swift version for the Haskell lens library by treating WritableKeyPath<T, U> ~= Lens' t u, U != V?, WritableKeyPath<T, U?> ~= Prism' t u, KeyPath<T, U> ~= Getter' t u and so on, with simple lifting operations such as lifting a KeyPath<T, U> to a KeyPath<T?, U?>, amongst other operations to compose keypaths in fancy ways. I'm not sure how well it would work, but I think it should be possible...

In any case, the bar for source-breaking changes is very high. Also, adding such a restriction arguably makes the language more irregular. It's not clear to me what is to be gained by adding the restriction.

[LucianoPAlmeida]

Fixed on master by #33601