-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Match type reduction failure when applied to a type containing a bounded wildcard #19607
Comments
Ah, that turns out to be an interesting one. The behavior is actually according to spec. If we look at the Matching algorithm at https://docs.scala-lang.org/sips/match-types-spec.html#matching, we can see what happens. We are trying to
So it picks I don't think there is a good solution to this problem. There is nothing that the matching algorithm could pick that would work. Neither The real solution would be to consider |
Or maybe I can make it work: main...dotty-staging:dotty:make-i19607-work ... although it still involves a (minor) change of spec. We might need to discuss that at the next SIP meeting, to see whether we could still accommodate it. /cc @anatoliykmetyuk |
Perhaps we can consider this a "spec bug", since the intent of the spec was clearly to pick something that would always work (see text in parentheses), but picking |
As demonstrated by scala/scala3#19607, picking `H` does *not* in fact always work. It was always the intent of the spec to pick an instantiation that would make subtyping work, but the particular choice was wrong. IMO this is therefore clearly a spec bug, and we can address it irrespective of compatibility concerns.
…ds. (#19627) When matching in a match type, if we encounter a `TypeBounds` scrutinee and we have a wildcard capture on the right, we used to pick the `hi` bound "because anything between between `lo` and `hi` would work". It turns out that *nothing* between `lo` and `hi` works when the type constructor is invariant. Instead, we must be keep the type bounds, and instantiate the wildcard capture to a wildcard type argument. This is fine because a wildcard capture can never be referred to in the body of the case. However, previously this could never happen in successful cases, and we therefore used the presence of a `TypeBounds` in the `instances` as the canonical signal for "fail as not specific". We now use a separate `noInstances` list to be that signal. This change departs from the letter of the spec but not from its spirit. As evidenced by the wording, the spec always *intended* for "the pick" to one that would always succeed. We wrongly assumed `hi` was always working. --- Companion PR to fix the spec/SIP: scala/improvement-proposals#77
As demonstrated by scala/scala3#19607, picking `H` does *not* in fact always work. It was always the intent of the spec to pick an instantiation that would make subtyping work, but the particular choice was wrong. IMO this is therefore clearly a spec bug, and we can address it irrespective of compatibility concerns.
Compiler version
3.4.0-RC4
Minimized code
Compiler output
Expectation
No compile error
The text was updated successfully, but these errors were encountered: