This seems a very nice twist - while slightly more verbose, what we get
back is that patterns "say what they mean", and there's no subtle type
dependency analysis which determines the fate of null. This had me a bit
worried, since this creates an action-at-a-distance between the type of
the target expression and the selected semantics of a match expression -
which is not unlike when we have overload resolution depending on the
results of type inference (albeit to a lesser degree).
Maurizio
On 21/01/2021 18:52, Brian Goetz wrote:
Here's what is new: the treatment of guards as composable patterns.
With that, we can write a "non-nullable" nested pattern like:
case Foo(Object o & false(o == null)):
or
case Foo(Object o) & false(o == null):
