No longer able to extract a type from an intersection

[johnhungerford]

Compiler version

Does not compile on 3.4.0 (or 3.0.0, 3.1.0, 3.2.0, 3.3.0)

Does compile in 2.13.12

Minimized code

sealed trait InIntersection[I, A] {
    type R // Remaining types in the intersection Int
}

object InIntersection {
    implicit def derived[A, R0]: InIntersection[A & R0, A] = new InIntersection[A & R0, A] {
        type R = R0
    }
}

implicitly[InIntersection[Int & String, Int]]

Output

[error] No given instance of type IntersectionBug$_.this.InIntersection[Int & String, Int] was found for parameter e of method implicitly in object Predef.
[error] I found:
[error] 
[error]     this.InIntersection.derived[A, R0]
[error] 
[error] But method derived in object InIntersection does not match type IntersectionBug$_.this.InIntersection[Int & String, Int].
[error] implicitly[InIntersection[Int & String, Int]]
[error]                                              ^
Error compiling project (Scala 3.4.0, JVM (17))
Compilation failed

Expectation

I would expect it to compile. It does compile with scala 2.13.12 (if I change the & to with).

[som-snytt]

It does compile with scala 2.13.12 (if I change the & to with).

You want -Xsource:3.

[odersky]

Minimization:

class InIntersection[I, A]

def derived[A, R0]: InIntersection[A & R0, A] = new InIntersection[A & R0, A]

val x: InIntersection[Int & String, Int] = derived // error

Here is the error with -explain

-- [E007] Type Mismatch Error: ../new/test.scala:5:43 --------------------------
5 |val x: InIntersection[Int & String, Int] = derived
  |                                           ^^^^^^^
  |                               Found:    InIntersection[A & R0, A]
  |                               Required: InIntersection[Int & String, Int]
  |
  |                               where:    A  is a type variable
  |                                         R0 is a type variable
  |-----------------------------------------------------------------------------
  | Explanation (enabled by `-explain`)
  |- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  |
  | Tree: derived[A, R0]
  | I tried to show that
  |   InIntersection[A & R0, A]
  | conforms to
  |   InIntersection[Int & String, Int]
  | but none of the attempts shown below succeeded:
  |
  |   ==> InIntersection[A & R0, A]  <:  InIntersection[Int & String, Int]
  |     ==> Int  <:  A
  |       ==> Int  <:  A in frozen constraint
  |         ==> Int  <:  Int & String in frozen constraint
  |           ==> Int  <:  String in frozen constraint  = false
  |       ==> add constraint A >: Int , constraint =  uninstantiated variables: A, R0  constrained types: [A, R0]: InIntersection[A & R0, A]  bounds:      A >: Int & String <: Int & String      R0 >: Int & String  ordering:  co-deps:  contra-deps: 
  |         ==> Int  <:  Int & String in frozen constraint
  |           ==> Int  <:  String in frozen constraint  = false
  |         ==> Int  <:  Int & String
  |           ==> Int  <:  String  = false
  |
  | The tests were made under a constraint with:
  |  uninstantiated variables: A, R0
  |  constrained types: [A, R0]: InIntersection[A & R0, A]
  |  bounds:
  |      A
  |      R0
  |  ordering:
  |  co-deps:
  |  contra-deps:
   -----------------------------------------------------------------------------

Interestingly it compiles OK if the second type parameter is dropped:

class InIntersection[I]

def derived[A, R0]: InIntersection[A & R0] = new InIntersection[A & R0]

var x: InIntersection[Int & String] = derived // OK

[odersky]

Hint to issue reporters: If possible avoid reference to summon, implicitly, =:=, or <:<, or other implicit mechanisms. It just increases the footprint where the error could be. Of course, if the error is linked to implicits and cannot be reproduced without them, do report it like that.

[odersky]

The example also compiles if the order of parameters is reversed:

class InIntersection[A, I]

def derived[A, R0]: InIntersection[A, A & R0] = new InIntersection[A, A & R0]

var x: InIntersection[Int, Int & String] = derived

What happens in the failing example is that the first constraint A & R0 =:= Int & String is handled first. It results in both A and R0 being instantiated to Int & String. Then the second constraint A =::= Int fails.

[odersky]

We could maybe try to re-order the comparison of type arguments, delaying constraints that look hard. A hard constraint would be one that has a & on the LHS or an | on the RHS, since both of these need a fork via either.