> On Oct 27, 2022, at 3:25 PM, [email protected] wrote: > >>> Either i can use >>> case Point p -> >>> >>> or >>> case Point(var x, var y) -> >>> >>> but this is not valid anymore >>> case Point(var x, var y) p -> ... >> >> Can always do this, right? >> >> case Point p where p instanceof Point(var x, var y) -> > > Gavin already proposed that, in France, we have a sentence for that > Why do it the easy way when you can do it the hard way ? [1]
I dunno, I guess I don't really understand the motivation. If you do 'case Point(var x, var y)', that solves your problem: won't compile if a new component comes along. If you do 'case Point p', it *will* compile, of course, just like if you declare a field of that type. It won't check the arity, because we don't check properties of classes based on a random mention of them. I guess you're really looking for something like 'case Point(#2#) p', some compact way to assert that the class you're talking about still has 2 record components. But... this is such a niche-sounding concern to me, I don't see why *records* are the one kind of class in Java for which such a feature would be important. In any case, good news—even though we don't have this dedicated feature, there are various ways you can mention the record class in a record pattern and get the compiler to make this check. Just costs a few more characters. 🤷♂️ > moreover this pattern+where is not exhaustive on Point. Ah, that's interesting. I think we need to think more about what features or idioms we'll recommend for people to do assignment-like decomposition. I'm not sure that's settled yet. If we arrive at 'RecordType instanceof RecordPattern' as a common decomposition idiom, then I think it would be reasonable to expect the analysis of guards (and probably DA/DU, etc....) to special-case this and realize it will always be true.
