[patterns] on treatment of null

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Fri Jul 7 15:17:23 UTC 2017



On 07/07/17 16:05, Dmitry Petrashko wrote:
>
> Hi Maurizio,
> thanks for a good writeup.
>
> I’ll provide some perspective coming from Scala.
>
> At the very beginning of your writeup you say:
>
>     In order to further simplify the discussion, let's also ignore var
>     patterns; in fact, a pattern such as var x can always be thought
>     of a type-test pattern where the type of the test is implicitly
>     inferred by the compiler using some target-type information. in
>     other words, given a target expression s whose static type is
>     String, the following two snippets should behave in the same fashion:
>
>     if (s matches String x) { ... }
>
>     if (s matches var x) { ... }
>
> This is not the case in Scala.
>
> |scala> (null: String) match {case a => true} // variable bound. Though 
> variable has type String it is null. res0: Boolean = true scala> 
> (null: String) match {case _: String => true} // type test. Null will 
> fail it. scala.MatchError: null |
>
> Even if Java would decide to go towards the path you’ve described, It 
> would be nice to be able to accommodate
> alternative behaviour that Scala has.
>
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.
>
> 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?

Maurizio
>
> Based on our experience it works well in practice, but it’s not clear 
> how applicable our experience
> would be in Java.
>
> Best regards,
> Dmitry
>
> On 7 Jul 2017, at 14:56, Maurizio Cimadamore wrote:
>
>     Hi,
>     over the last few weeks we've been exploring the twisted
>     relationship between patterns and nulls. This document:
>
>     http://cr.openjdk.java.net/~mcimadamore/nulls-patterns.html
>     <http://cr.openjdk.java.net/%7Emcimadamore/nulls-patterns.html>
>
>     provides some (hopefully helpful) insights into what the design
>     space looks like.
>
>     tl;dr;
>
>     Looks like trying to force the same rule on all patterns,
>     regardless of where they appear, leads to problems. Distinguishing
>     between toplevel and nested patterns provides a good basis to
>     handle null in a more predictable/flexible fashion.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20170707/b64f0bc7/attachment.html>


More information about the amber-spec-experts mailing list