Referring to Tagir’s example in [1]
if (obj instanceof String str) {
System.out.println(str.toLowerCase()); // str refers to
pattern binding
} else {
System.out.println(str.toLowerCase()); // str refers to the field
}
which is mentioned as Swiss cheese issue in the replies to [1]
From our development efforts in ecj (Eclipse Compiler for Java) for this feature:
For that reason we propose a compromise, whereby "swiss cheese" is allowed for pattern variables, but disallowed for fields shining through in the holes of the cheese. This can be achieved by disallowing a pattern variable to shadow a field. This is a significantly smaller cost than having to invent cascades of names for a cascade of pattern variables (the original motivation for swiss cheese – as in Gavin’s message[2]).
With this proposals users have a chance to find a declaration by looking only up and out starting from the point of reference. For the implementation in ecj this makes a huge difference, because admitting swiss cheese involving fields would require us to abandon the strict separation of compilation phases 'resolve' and 'flow analysis'. Since this separation is one of the fundamental design principles in the ecj compiler, a change would require a major re-architecting of the compiler, draining resources from other, high priority tasks.
In summary, we don't object to using flow criteria to determine whether or not a variable is in scope, we only object to flow criteria to *select* between different same-named variables, that could be in scope at the same location. As far as we can see, this situation is specific to fields and hence a change specific to fields should avoid the major complexity.
In a spec, one could optionally generalize in a way that a pattern variable may never shadow any other variable (local or field) that is in scope.
