In the comments, there is confusion as to why something like the following doesn't work.
protocolP {}
structS: P {}
funcf<T: P>() -> T {
S()
}
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.
The text was updated successfully, but these errors were encountered:
Additional Detail from JIRA
md5: 633fbda3b16cd7b6ddcdeea27823266e
Issue Description:
See thread: https://twitter.com/krzyzanowskim/status/1388907400783085577
In the comments, there is confusion as to why something like the following doesn't work.
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.
The text was updated successfully, but these errors were encountered: