[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