[patterns] on treatment of null

[Dmitry Petrashko]

On 7 Jul 2017, at 17:17, Maurizio Cimadamore wrote:
> I understand. In our mind, 'var' is simply a way to tell the compiler 
> "type missing here, please fill it out" - and we'd like to keep the 
> type inference as orthogonal as possible from other related semantics.

This is also how it behaves in scala if you don’t ascribe the type in 
pattern. The type will be filled in by typer. Based on 
http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html

```
exprswitch(b) {
         case Box(var n) -> n;
     };
```

is equivalent to this in Scala:

```
x match {
         case Box(n) => n;
     };
```

Or am I misinterpreting?

>>
>> In Scala, the runtime uses |instanceof| test (Option 1 in your 
>> writeup),
>> while the exhaustivity checkers uses type system and assumes absence 
>> of null (Option 2).
>> For generics, we issue a warning that type parameters are unchecked.
>> Have you considered this option?
>>
> So, you are saying that Scala does option 1 - but it tones it a bit 
> down by emitting a warning (rather than an harsh error) when generic 
> types are found.
>
> This seems a sensible option - the only thing I don't understand from 
> your description - what does Scala do for nested patterns? Is it 
> another instanceof? If that's the case, does it means that I cannot 
> match against a List whose head is null with a normal nested type test 
> pattern?

Scala behaves the same way for top level and nested patters:

Lets say that we have `case class Cons(hd: Object, tl: Cons)`

```
x match {
  case Cons(a, b) => 1       // will match only if `x instanceof Cons`. 
will match even if a is null and b is null
  case Cons(a, b: Cons) => 2 // will not match if b is null, but a may 
be null
  case a: Cons => 3          // will not match null, is equivalent to 
the first option
  case a => 4                // always matches
}
```

now, details about type parameters and type inference:

```
case class Cons[T](hd: T, tl: Cons)

x match {
  case Cons(a, b) => 1       // a will be inferred to be Any, our top 
type
  case Cons[Int](a, b) => 2  // warning will be emitted that Cons[Int] 
is unchecked.
}

```

In practice, people rarely see this warning due to important observation 
that compiler uses:

```
case class Cons[T](hd: T, tl: Cons) extends Seq[T]

val x: Seq[Int] = ???

x match {
  case Cons[Int](a, b) => 2  // a warning will not be emitted, as we 
know that T is the same as in Seq and we “trust” x.
}

```


Best,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20170707/724f9a0b/attachment-0001.html>