title: Pattern matching on values of compound types - is it a compiler bug?
body: <p>I've stumbled upon a bit of a mysterious (at least to me) compiler behaviour when attempting to pattern match values with compound types, that I suspect might be a compiler bug. Before filing a bug report though, I would be glad if someone more knowledgeable than me could have a look at this and maybe provide some bit of explanation for what is going on.</p>
  
  <p>We start with a little hierarchy of traits and case classes:</p>
  
  <pre><code>sealed trait A
  case class A1() extends A
  case class A2() extends A
  
  sealed trait B
  </code></pre>
  
  <p>And we want to operate on values of compound type: <code>A with B</code></p>
  
  <pre><code>val a1: A with B = new A1() with B
  val a2: A with B = new A2() with B
  val as: Seq[A with B] = Seq(a1, a2)
  </code></pre>
  
  <p>First, I've tried to pattern match using case class extractors:</p>
  
  <pre><code>Seq(a1, a2) foreach {
    case A1() =&gt; println("a1")
    case A2() =&gt; println("a2")
  }
  </code></pre>
  
  <p>The above fails to compile due to type mismatch:</p>
  
  <pre><code>&lt;console&gt;:21: error: constructor cannot be instantiated to expected type;
   found   : A1
   required: A with B
           case A1() =&gt; println("a1")
                ^
  &lt;console&gt;:22: error: constructor cannot be instantiated to expected type;
   found   : A2
   required: A with B
           case A2() =&gt; println("a2")
                ^
  </code></pre>
  
  <p>Second, I've replaced extractor usage with instance type matching:</p>
  
  <pre><code>as foreach {
    case _: A1 =&gt; println("a1")
    case _: A2 =&gt; println("a2")
  }
  </code></pre>
  
  <p>The above does compile and <em>does</em> indeed work, printing "a1" and "a2" to the screen, but emits an erroneous warning about unreachable code:</p>
  
  <pre><code>&lt;console&gt;:23: warning: unreachable code
           case _: A2 =&gt; println("a2")
  </code></pre>
  
  <p>Surprisingly, making <code>A</code> not <code>sealed</code> gets rid of the warning (although the first pattern match still doesn't compile).</p>
  
  <p>So, here come the questions:</p>
  
  <ol>
  <li>Should the first pattern match compile? If not, then why exactly?</li>
  <li>Is the warning emitted for the second pattern match plain wrong or have I just been lucky and there <em>are</em> cases when this match could take a wrong branch?</li>
  <li>Should I file a bug report or maybe it's a long known issue I've just missed?</li>
  </ol>
  
  <p>I've tested it on <code>2.11.7</code> and <code>2.11.8</code>.</p>