sourcekit-lsp
sourcekit-lsp copied to clipboard
apple
[SR-13653] SourceKit-LSP: show full type signature in autocompletion
| 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"
}
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.
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.
