Imported From: https://issues.scala-lang.org/browse/SI-8301?orig=1
Reporter: @retronym
Affected Versions: 2.11.0-M3
See #8304

@retronym said:
scala/scala#3545

@retronym said (edited on Feb 17, 2014 9:27:42 PM UTC):
Copying Eugene's unanswered questions from the duplicate ticket:

This is a change in behavior in comparison with 2.10.x (regression?).
FreeTypeSymbol is now designated as volatile, which prevents: 1) pattern matching against vals of such type, 2) extension methods that return such type. If I change `FreeTypeSymbolApi with Symbol` to `Symbol with FreeTypeSymbolApi`, it makes everything work fine, but then erasures of Symbol and FreeTypeSymbol start clashing.
I have several questions actually:
1) Is the change in volatility correct? FreeTypeSymbol transitively extends AnyRef, so why is it volatile?
2) Why do we disregard extension methods that return volatile types?

@xeno-by said:
So as you can see, question #1 shows my lack of knowledge about volatility. I misread the spec and ended up being confused. Nevertheless, it would be nice if you could elaborate on what volatility is, because comments on isVolatile also don't help much.

3. I actually have another question, which is why values of volatile types can't be matched as-is:

// cf. pos/t8300-patmat.scala
trait Universe {
  type Name >: Null <: AnyRef with NameApi
  trait NameApi

  type TermName >: Null <: TermNameApi with Name
  trait TermNameApi extends NameApi
}

object Test extends App {
  val u: Universe = ???
  import u._

  locally {
    val ScalaName: TermName = ???
    ??? match {
      case ScalaName => ???
    }
  }
}

t8300-patmat.scala:17: error: stable identifier required, but ScalaName found.
 Note that value ScalaName is not stable because its type, Test.u.TermName, is volatile.
      case ScalaName => ???
           ^
one error found

@retronym said:
I'll take a better look tomorrow but in the meantime check out scala/scala#2374

@adriaanm said:
The only reason I can think of is that they can be bound to a variable (x@ScalaName), so that x would then have to be tracked as unstable. We already do that through its type. I think it's more likely to be fall out of conflating volatility and stability. For stable identifier patterns, I don't see a compelling reason to exclude volatile types.

@xeno-by said:
Adriaan, I've just submitted #8304 with critical priority since it's a regression since 2.10.x. Don't know whether I should've marked it as a blocker.