[SR-13653] SourceKit-LSP: show full type signature in autocompletion

[xAlien95]

Previous ID	SR-13653
Radar	rdar://problem/69958775
Original Reporter	@xAlien95
Type	Improvement

Attachment: Download

Additional Detail from JIRA

| | | |------------------|-----------------| |Votes | 0 | |Component/s | SourceKit-LSP | |Labels | Improvement | |Assignee | None | |Priority | Medium | md5: 082a2c11b6e53a2c078c70bdfa52294a

Issue Description:

Currently, when typing max you get

max(_ x: Comparable, _ y: Comparable) -> Comparable

as a suggested type signature, which may led the user into thinking that the function accepts existential protocol types instead of a unique type "T: Comparable" in both the arguments and result (see attached image, P1 and P2 are protocols, C1 is a class).

It may be more useful to show

max<T: Comparable>(_ x: T, _ y: T) -> T

as suggested type signature, although less readable.

We have the same issue when typing in the function body:

protocol SomeProtocol {}
class SomeClass {}

func foo<T: Collection>(_ x: T) {
    x  // suggested as "x: Collection" instead of "x: T"
}

func bar<T: SomeClass & SomeProtocol>(_ x: T) { 
    x // suggested as "x: SomeProtocol" instead of "x: T" 
}

[typesanitizer]

@swift-ci create

[typesanitizer]

Fwiw, I agree with your point; the two types are different and conflating them is not the way to go. Maybe it looks cleaner, but it's conceptually incorrect, which is a negative for something that is presented frequently to a developer.

[xwu]

https://forums.swift.org/t/should-the-type-double-string-be-never/40908/12

The link above describes a real-world situation in which the current behavior actively misled a user to believe that they were using an existential type when they were not. Given the pervasive misunderstanding of existentials and generics, this sort of mixup is, arguably, actively confusing users and steering them into the wrong path.