|
| 1 | +layout: doc-page |
| 2 | +title: The Matchable Trait |
| 3 | +--- |
| 4 | + |
| 5 | +A new trait `Matchable` controls the ability to pattern match. |
| 6 | + |
| 7 | +### The Problem |
| 8 | + |
| 9 | +The Scala 3 standard library has a type `IArray` for immutable |
| 10 | +arrays that is defined like this: |
| 11 | + |
| 12 | +```scala |
| 13 | + opaque type IArray[+T] = Array[_ <: T] |
| 14 | +``` |
| 15 | +The `IArray` type offers extension methods for `length` and `apply`, but not for `update`; hence it seems values of type `IArray` cannot be updated. |
| 16 | + |
| 17 | +However, there is a potential hole due to pattern matching. Consider: |
| 18 | +```scala |
| 19 | +val imm: IArray[Int] = ... |
| 20 | +imm match |
| 21 | + case a: Array[Int] => a(0) = 1 |
| 22 | +``` |
| 23 | +The test will succeed at runtime since `IArray`s _are_ represented as |
| 24 | +`Array`s at runtime. But if we allowed it, it would break the fundamental abstraction of immutable arrays. |
| 25 | + |
| 26 | +__Aside:__ One could also achieve the same by casting: |
| 27 | +```scala |
| 28 | +imm.asInstanceOf[Array[Int]](0) = 1 |
| 29 | +``` |
| 30 | +But that is not as much of a problem since in Scala `asInstanceOf` is understood to be low-level and unsafe. By contrast, a pattern match that compiles without warning or error should not break abstractions. |
| 31 | + |
| 32 | +Note also that the problem is not tied to opaque types as match selectors. The following slight variant with a value of parametric |
| 33 | +type `T` as match selector leads to the same problem: |
| 34 | + |
| 35 | +```scala |
| 36 | +def f[T](x: T) = x match |
| 37 | + case a: Array[Int] => a(0) = 0 |
| 38 | +f(imm) |
| 39 | +``` |
| 40 | +Finally, note that the problem is not linked to just opaque types. No unbounded type parameter or abstract type should be decomposable with a pattern match. |
| 41 | + |
| 42 | +### The Solution |
| 43 | + |
| 44 | +There is a new type `scala.Matchable` that controls pattern matching. When typing a pattern match of a constructor pattern `C(...)` or |
| 45 | +a type pattern `_: C` it is required that the selector type conforms |
| 46 | +to `Matchable`. If that's not the case a warning is issued. For instance when compiling the example at the start of this section we get: |
| 47 | +``` |
| 48 | +> sc ../new/test.scala -source 3.1 |
| 49 | +-- Warning: ../new/test.scala:4:12 --------------------------------------------- |
| 50 | +4 | case a: Array[Int] => a(0) = 0 |
| 51 | + | ^^^^^^^^^^ |
| 52 | + | pattern selector should be an instance of Matchable, |
| 53 | + | but it has unmatchable type IArray[Int] instead |
| 54 | +``` |
| 55 | +To allow migration from Scala 2 and cross-compiling |
| 56 | +between Scala 2 and 3 the warning is turned on only for `-source 3.1-migration` or higher. |
| 57 | + |
| 58 | +`Matchable` is a universal trait with `Any` as its parent class. It is |
| 59 | +extended by both `AnyVal` and `AnyRef`. Since `Matchable` is a supertype of every concrete value or reference class it means that instances of such classes can be matched as before. However, match selectors of the following types will produce a warning: |
| 60 | + |
| 61 | + - Type `Any`: if pattern matching is required one should use `Matchable` instead. |
| 62 | + - Unbounded type parameters and abstract types: If pattern matching is required they should have an upper bound `Matchable`. |
| 63 | + - Type parameters and abstract types that are only bounded by some |
| 64 | + universal trait: Again, `Matchable` should be added as a bound. |
| 65 | + |
| 66 | +`Matchable` is currently a marker trait without any methods. Over time |
| 67 | +we might migrate methods `getClass` and `isInstanceOf` to it, since these are closely related to pattern-matching. |
| 68 | + |
0 commit comments