Intersection types in patterns

[Guy Steele]

> On Oct 20, 2018, at 12:42 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
>>>    case Point(var x, var y) p: ...
>>> 
>> 
>> Is there a situation where you could have reached that case without
>> having a reference to p? If I've understood so far:
>> 
>> SomeSuperTypeOfPoint q;
>> 
>> switch (q) {
>>   case Point(var x, var y) p: ... // p == q and p : Point
>> }
> 
> Yes, you could have gotten there via
> 
>    switch (getAnObjectForMe()) { 
>        case Point(var x, var y) p: 
>    }
> 
> But, one could always refactor to 
> 
>    Object o = getAnObjectForMe();
>    switch (o) { 
>        case Point(var x, var y) p: 
>    }
> 
> and we’re back to the previous case.  

I believe that @-patterns (I’ll call them that for now) are especially useful in nested situations, where it is not convenient to do that kind of refactoring:

   Object o = getAnObjectForMe();
   switch (o) { 
       case Line(Point(var x1, var y1) p1, Point(var x2, var y2) p2):
		// Now you have your hands on the two points as well as their x and y coordinates
   }

So the question is how much that comes up in practice.

But even without nesting, the original example has the benefit of having verified the type of o and made it available in p with the matched type Point.

This is a very convenient idiom if you want to test x and y in order to decide which method of p to call, for example.

—Guy