> From: "Brian Goetz" <brian.go...@oracle.com>
> To: "Remi Forax" <fo...@univ-mlv.fr>, "amber-spec-experts"
> <amber-spec-experts@openjdk.java.net>
> Sent: Tuesday, April 19, 2022 10:02:22 PM
> Subject: Re: case null / null pattern (v2)
> With the currently specified semantics, the second pattern is dead, because
> switches will only match null at the top level with a case null. This was an
> accommodation to clarify that that the null-hostility of switch is a property
> of switch, not patterns, and make it more clear when switch will NPE.
"case Foo fooButNull" is equivalent to "case null" but with a binding typed as
Foo that's why i ask if it should even compile,
the compiler should ask for an explicit "case null".
But because there is no null pattern, we can not do that if it appears as a
sub-pattern.
> Regardless, what you're asking for is a more precise remainder checking. The
> first pattern matches all non-null Foo; because no case matches null, you're
> asking that we recognize that there is a dominance relationship here. This is
> reasonable to consider (though harder, because null makes everything harder.)
I'm not sure it should be include in the dominance, because Foo(int) is a
subtype of Foo, so
case Foo foo ->
case Foo(int _) foo ->
should not compile.
The ideal solution for me is to disable that pattern (record pattern + type
pattern on the same type) and allow the null pattern, but as you said earlier,
if we allow case(null), it's opening the pandora box because people will want
to write case Foo(7).
Rémi
> On 4/18/2022 6:49 PM, Remi Forax wrote:
>> I've found a way to encode the null pattern if you have a record
>> record Foo(int x) { }
>> Foo foo = ...
>> return switch(foo) {
>> case Foo(int _) foo -> "i'm a foo not null here !";
>> case Foo fooButNull -> "i can be only null here !";
>> };
>> I wonder if allowing those two patterns, a record pattern and a type pattern
>> using the same type is a good idea or not, it seems a great way to obfuscate
>> thing.
>> Rémi
