Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
xAlien95 opened this issue Oct 5, 2020 · 3 comments
Open

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

xAlien95 opened this issue Oct 5, 2020 · 3 comments
Labels
enhancement New feature or request

Comments

@xAlien95
Copy link

xAlien95 commented Oct 5, 2020

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
Copy link

@swift-ci create

@typesanitizer
Copy link

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
Copy link
Contributor

xwu commented Oct 5, 2020

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.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 5, 2022
@ahoppen ahoppen added enhancement New feature or request and removed Improvement labels Aug 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@xwu @shahmishal @ahoppen @xAlien95 @typesanitizer