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:try/ttp.scala:10:7---------------------------------------------------10| (_: TC[?]) <-List[TC[?]]() // error|^^^^^^^^|pattern'stypeTC[_] is more specialized than the right hand side expression'stypeTC[?]
||If the narrowing is intentional, this can be communicated by adding the `case` keyword before the full pattern,
|which will result in a filtering for expression (using `withFilter`).
|This patch can be rewritten automatically under -rewrite -source 3.2-migration.
Expectation
No error, the pattern is not more specialized and will always match.
The problem is easier to debug if we give a name to the type pattern instead of using ?:
for
(_: TC[xx]) <-List[TC[?]]() // errordo ()
10| (_: TC[xx]) <-List[TC[?]]() // error|^^^^^^^^^|pattern'stypeTC[xx] is more specialized than the right hand side expression'stypeTC[?]
because pat is Typed(Ident(_),AppliedTypeTree(Ident(TC),List(Bind(xx,Ident(_))))) with pat.tpe being AppliedType(TypeRef(ThisType(TypeRef(NoPrefix,module class <empty>)),trait TC),List(TypeRef(NoPrefix,type xx)))
In both cases, the problem is that pattern matching introduces a local TypeRef and symbol to represent the pattern-bound type variable (if we write ? then we get a pattern-bound type variable called _ which is a bit confusing). They are introduced in:
for wildcards (the comment claims that they are subsequently eliminated by indexPattern but this is no longer the case since 7801c57 which harmonized non-wildcard and wildcard handling).
This could be fixed by carefully transforming pattern types in checkIrrefutable to replace TypeRefs of pattern-bound type variables by their bounds. That feels a bit ad-hoc and inefficient, but I can't think of a more general fix that wouldn't break actual use of pattern-bound type variables.
Workaround
Define type AnyTC = TC[?] and match on AnyTC.
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
Compiler version
3.7.0 (and latest nightly)
Minimized code
Output
Expectation
No error, the pattern is not more specialized and will always match.
The problem is easier to debug if we give a name to the type pattern instead of using
?
:The subtype check that fails is
scala3/compiler/src/dotty/tools/dotc/typer/Checking.scala
Line 1031 in 515c3e1
pat
isTyped(Ident(_),AppliedTypeTree(Ident(TC),List(Bind(xx,Ident(_)))))
withpat.tpe
beingAppliedType(TypeRef(ThisType(TypeRef(NoPrefix,module class <empty>)),trait TC),List(TypeRef(NoPrefix,type xx)))
In both cases, the problem is that pattern matching introduces a local TypeRef and symbol to represent the pattern-bound type variable (if we write
?
then we get a pattern-bound type variable called_
which is a bit confusing). They are introduced in:scala3/compiler/src/dotty/tools/dotc/typer/Typer.scala
Line 2814 in 515c3e1
scala3/compiler/src/dotty/tools/dotc/typer/Typer.scala
Lines 3905 to 3913 in 515c3e1
This could be fixed by carefully transforming pattern types in
checkIrrefutable
to replace TypeRefs of pattern-bound type variables by their bounds. That feels a bit ad-hoc and inefficient, but I can't think of a more general fix that wouldn't break actual use of pattern-bound type variables.Workaround
Define
type AnyTC = TC[?]
and match onAnyTC
.The text was updated successfully, but these errors were encountered: