Ref scala/bug#4364

The specification clarification that is needed is this: What should the pattern matcher do when encountering a `null` and an extractor pattern?

As it stands, SLS does not say anything about `null` for extractor pattern, which leads:
- Pattern matcher will happily pass `null` into your extractor.
- I can write a `null`-matching extractor MyNull.
- Thus, all extractor authors must check for `null` if they would like to access the passed in argument `x`. See `Animal` example below.

There are potentially two things we can do.
1. Be ok with the status quo. Make sure we handle `null` in all our extractors.
2. Not be ok with the status quo. Suppose we would want extractor pattern to be non-null values only, then that's a spec change and change in pattern matcher's behavior. It might also break existing code that handled `null` in ever so subtle way.

I think Paul is suggesting option 1 in scala/bug#4364, not spec change. Given that there are no outcry of `null` handling besides scala/bug#2241, I think that's fine too.

### MyNull

```scala
scala> object MyNull {
     |   def unapply(x: AnyRef): Option[AnyRef] =
     |     if (x eq null) Some(x) else None
     | }
defined object MyNull

scala> null match { case MyNull(_) => "yes"; case _ => "no" }
res4: String = yes
```

### Animal

```scala
scala> object Animal {
     |   def unapply(x: AnyRef): Option[AnyRef] =
     |     if (x.toString == "Animal") Some(x)
     |     else None
     | }
defined object Animal

scala> null match { case Animal(_) => "yes"; case _ => "no" }
java.lang.NullPointerException
  at Animal$.unapply(<console>:13)
  ... 37 elided
```

Ref scala/bug#4364

The specification clarification that is needed is this: What should the pattern matcher do when encountering a `null` and an extractor pattern?

As it stands, SLS does not say anything about `null` for extractor pattern, which leads:
- Pattern matcher will happily pass `null` into your extractor.
- I can write a `null`-matching extractor MyNull.
- Thus, all extractor authors must check for `null` if they would like to access the passed in argument `x`. See `Animal` example below.

There are potentially two things we can do.
1. Be ok with the status quo. Make sure we handle `null` in all our extractors.
2. Not be ok with the status quo. Suppose we would want extractor pattern to be non-null values only, then that's a spec change and change in pattern matcher's behavior. It might also break existing code that handled `null` in ever so subtle way.

I think Paul is suggesting option 1 in scala/bug#4364, not spec change. Given that there are no outcry of `null` handling besides scala/bug#2241, I think that's fine too.

### MyNull

```scala
scala> object MyNull {
     |   def unapply(x: AnyRef): Option[AnyRef] =
     |     if (x eq null) Some(x) else None
     | }
defined object MyNull

scala> null match { case MyNull(_) => "yes"; case _ => "no" }
res4: String = yes
```

### Animal

```scala
scala> object Animal {
     |   def unapply(x: AnyRef): Option[AnyRef] =
     |     if (x.toString == "Animal") Some(x)
     |     else None
     | }
defined object Animal

scala> null match { case Animal(_) => "yes"; case _ => "no" }
java.lang.NullPointerException
  at Animal$.unapply(<console>:13)
  ... 37 elided
```

Ref scala/bug#4364
This is a general fix for scala/bug#2241 and scala/bug#8787.

scala/bug#4364 raises the question of what should the pattern matcher do when encountering a `null` and an extractor pattern. As it stands, SLS does not say anything about `null` for extractor pattern, which leads:
- Pattern matcher will happily pass `null` into your extractor.
- I can write a `null`-matching extractor MyNull.
- Thus, all extractor authors must check for `null` if they would like to access the passed in argument `x`.

There are potentially two things we can do.
1. Be ok with the status quo. Clarify in SLS that all extractor authors must handle `null`.
2. Not be ok with the status quo. Change SLS and implementation such that `null` is treated as no match (empty).

I've already sent option 1 as scala#6374.
This implements option 2.

Ref scala/bug#4364
This is a general fix for scala/bug#2241 and scala/bug#8787.

scala/bug#4364 raises the question of what should the pattern matcher do when encountering a `null` and an extractor pattern. As it stands, SLS does not say anything about `null` for extractor pattern, which leads:
- Pattern matcher will happily pass `null` into your extractor.
- I can write a `null`-matching extractor MyNull.
- Thus, all extractor authors must check for `null` if they would like to access the passed in argument `x`.

There are potentially two things we can do.
1. Be ok with the status quo. Clarify in SLS that all extractor authors must handle `null`.
2. Not be ok with the status quo. Change SLS and implementation such that `null` is treated as no match (empty).

I've already sent option 1 as scala#6374.
This implements option 2.

Ref scala/bug#4364
This is a general fix for scala/bug#2241 and scala/bug#8787.

scala/bug#4364 raises the question of what should the pattern matcher do when encountering a `null` and an extractor pattern. As it stands, SLS does not say anything about `null` for extractor pattern, which leads:
- Pattern matcher will happily pass `null` into your extractor.
- I can write a `null`-matching extractor MyNull.
- Thus, all extractor authors must check for `null` if they would like to access the passed in argument `x`.

There are potentially two things we can do.
1. Be ok with the status quo. Clarify in SLS that all extractor authors must handle `null`.
2. Not be ok with the status quo. Change SLS and implementation such that `null` is treated as no match (empty).

I've already sent option 1 as scala#6374.
This implements option 2.

Ref scala/bug#4364
This is a general fix for scala/bug#2241 and scala/bug#8787.

scala/bug#4364 raises the question of what should the pattern matcher do when encountering a `null` and an extractor pattern. As it stands, SLS does not say anything about `null` for extractor pattern, which leads:
- Pattern matcher will happily pass `null` into your extractor.
- I can write a `null`-matching extractor MyNull.
- Thus, all extractor authors must check for `null` if they would like to access the passed in argument `x`.

There are potentially two things we can do.
1. Be ok with the status quo. Clarify in SLS that all extractor authors must handle `null`.
2. Not be ok with the status quo. Change SLS and implementation such that `null` is treated as no match (empty).

I've already sent option 1 as scala#6374.
This implements option 2.

Until now, the spec did not say anything about `null` for extractor pattern, so that:
  - The pattern matcher would happily pass `null` into your extractor.
  - One could write a `null`-matching extractor `MyNull`.
  - But all extractor authors must consider `null` as a possible argument value.

No more! The pattern matcher inserts a non-`null` check before invoking an extractor,
so that you don't have to.

This is a general fix for scala/bug#2241, scala/bug#8787. See scala/bug#4364.

Until now, the spec did not say anything about `null` for extractor pattern, so that:
  - The pattern matcher would happily pass `null` into your extractor.
  - One could write a `null`-matching extractor `MyNull`.
  - But all extractor authors must consider `null` as a possible argument value.

No more! The pattern matcher inserts a non-`null` check before invoking an extractor,
so that you don't have to.

This is a general fix for scala/bug#2241, scala/bug#8787. See scala/bug#4364.