Possible RC2 regression - compilation error: method parameter types must match exactly
See original GitHub issueCompiler version
I am using 3.0.0-RC2. Code compiled in RC1 but not in RC2. Maybe a bug in RC1? (see i10666.scala and i10666.check)
Minimized code
Compiled in RC1:
class BaseToCompare
class IsA extends BaseToCompare
trait UseBase:
type TT <: BaseToCompare
def do1[T <: BaseToCompare](t:T): Unit
def do2(t:TT): Unit
object UseBaseA extends UseBase :
type TT = IsA
def do1[T <: IsA](t:T): Unit = ()
def do2(t:TT): Unit = ()
UseBaseA.do1(IsA())
Output
But now generates the error with RC2:
[error] 633 | object UseBaseA extends UseBase :
[error] | ^
[error] |object creation impossible, since def do1: [T <: examples.djl.autoencoder.experiments.BaseToCompare](t: T): Unit in trait UseBase in object experiments is not defined
[error] |(Note that
[error] | parameter T in def do1: [T <: examples.djl.autoencoder.experiments.BaseToCompare](t: T): Unit in trait UseBase in object experiments does not match
[error] | parameter T in def do1: [T <: examples.djl.autoencoder.experiments.IsA](t: T): Unit in object UseBaseA in object experiments
[error] | class IsA in object experiments is a subclass of class BaseToCompare in object experiments, but method parameter types must match exactly.)
Expectation
I am assuming that since:
summon[ IsA <:< BaseToCompare]
it should compile. Maybe an issue with variance I don’t understand? I was thinking it is equivalent to:
trait UseBase:
type TT <: BaseToCompare
def do1[T <: TT](t:T): Unit
def do2(t:TT): Unit
object UseBaseA extends UseBase :
type TT = IsA
def do1[T <: TT](t:T): Unit = ()
def do2(t:TT): Unit = ()
which does compile in RC2.
TIA
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (2 by maintainers)
Top Results From Across the Web
Understanding the limits of Scala GADT support - Stack Overflow
It seems to me that the class type parameters can easily be made less precise by upcasting, and as long as pattern matching...
Read more >proposal: spec: allow type parameters in methods · Issue ...
According to the Type parameters proposal, it is not allowed to define type parameters in methods. This limitation prevents to define ...
Read more >Compiler Error CS0425 - Microsoft Learn
In this article. The constraints for type parameter 'type parameter' of method 'method' must match the constraints for type parameter 'type ...
Read more >Backward Incompatible Changes in PHP 8.1, 8.0, 7.4, 7.3, 7.2 ...
Magic Methods will now have their arguments and return types checked if they have them declared. The signatures should match the following list:....
Read more >perlre - Perl regular expressions - Perldoc Browser
Any single character in a pattern matches that same character in the target string, unless the character is a metacharacter with a special...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
This is intentional, overrides allow result types to vary covariantly but not parameter types to vary contravariantly, it happened to work in some situations before but that wasn’t intentional, your initial example also fails in Scala 2.13.
Your second example fails because you wrote
type TT <: IsA
, so IsA can’t be passed where TT is expected, the following works:No,
type TT <: IsA
does not mean that you can use any type which is a subtype ofIsA
whereTT
is expected, it means that TT is some abstract type which is known to be a subtype ofIsA
.