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.
