While I'll take the agreement, I must point out that we haven't ditched
the "subtle type dependency." We would still use totality to determine
whether null is matched or not; what this gives us is the ability to opt
out of matching null in those cases by saying "but not nulls, please."
The action-at-a-distance is still there, but we can control it locally
if we don't like it.
On 1/21/2021 2:15 PM, Maurizio Cimadamore wrote:
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):
