On 21/01/2021 19:19, Brian Goetz wrote:
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.
I see - thanks for explaining. I thought for a moment that the proposal
implied having type test patterns matching nulls, but I now realize that
I have read too much between the lines.
Maurizio
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):
