// error: Combine Lab - Solutions.xcplaygroundpage:16:32: error: value of type '(some Publisher).Output' has no member 'bitWidth'
This is not great because the point is not that the member isn't present, the point is that you can't access knowledge about the member here. It's not a "the compiler can't do this" (it very well could), it's a "allowing this violates the language model" (barring future extensions).
I don't have a solid idea for what the new diagnostic should be. Here are some things that need to be made clear:
1. If Output had a protocol constraint for P, you could use those witnesses.
For every other property/method etc, you cannot use it, even if the concrete type is known. However, if the concrete type is known, perhaps we should consider offering a fix-it for exposing the concrete type in the function's signature?
typesanitizer
commented
4 years ago
Additional Detail from JIRA
| | | |------------------|-----------------| |Votes | 0 | |Component/s | Compiler | |Labels | Bug | |Assignee | None | |Priority | Medium | md5: c1363e1550ed3adb46c183f42540396eIssue Description:
Forum post: https://forums.swift.org/t/possible-compiler-bug-with-opaque-types-or-is-this-intended-behavior/36946
The user ends up getting a diagnostic
This is not great because the point is not that the member isn't present, the point is that you can't access knowledge about the member here. It's not a "the compiler can't do this" (it very well could), it's a "allowing this violates the language model" (barring future extensions).
I don't have a solid idea for what the new diagnostic should be. Here are some things that need to be made clear:
1. If Output had a protocol constraint for P, you could use those witnesses.