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.

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

[SR-14563] Provide more guidance on spotting misunderstanding about universal quantification #56915

typesanitizer opened this issue May 2, 2021 · 1 comment


Copy link

@typesanitizer typesanitizer commented May 2, 2021

Previous ID SR-14563
Radar rdar://problem/77437078
Original Reporter @typesanitizer
Type Improvement
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Improvement, DiagnosticsQoI, TypeChecker
Assignee None
Priority Medium

md5: 633fbda3b16cd7b6ddcdeea27823266e

Issue Description:

See thread:

In the comments, there is confusion as to why something like the following doesn't work.

protocol P {}
struct S: P {}
func f<T: P>() -> T {

I've definitely seen other people make this mistake too; they don't quite get why a universally quantified parameter can't be matched by a specific type.

What I think we should do: Maybe when we hit an error for "cannot convert return type of expression of type 'ConcreteType' to return type 'GenericParam'", there should be an additional helpful note describing what Slava describes in the thread, namely that substitution for GenericParam will be determined by the caller for the function, which could choose a type other than ConcreteType.

What I think we should NOT do: Suggesting an opaque type (as a fix-it) is probably not the way to go because: it would require non-local information; if there are other return statements which are trying to return other concrete types, then suggesting an opaque type would be misleading as it wouldn't work. (I could be wrong but) I don't think we use that kind of non-local information for diagnostics today.

Copy link

@typesanitizer typesanitizer commented May 2, 2021

@swift-ci create

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

1 participant