You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// 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.
2. 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?
The text was updated successfully, but these errors were encountered:
Additional Detail from JIRA
md5: c1363e1550ed3adb46c183f42540396e
Issue 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
// 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.
2. 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?
The text was updated successfully, but these errors were encountered: