Swiss Cheese Issue - Revisit?

Brian Goetz brian.goetz at
Wed May 6 18:03:33 UTC 2020

Since locals can shadow fields, not allowing pattern variables to shadow 
fields would likely seem to users as a strange kind of irregularity, and 
they surely won't understand why they have to make up a new name.  (And 
worse, when they find out, they won't like the answer: because someone 
else might write some confusing code.)

On 5/6/2020 12:06 PM, Manoj Palat wrote:
> Hi Brian,
>  Our proposal was  "disallowing a pattern variable to shadow a 
> field."  - I don't see that this approach was tried from your mail.
> Was this tried - Is there any problem which you see with this approach?
> Regards,
> Manoj
>     ----- Original message -----
>     From: Remi Forax <forax at>
>     Sent by: "amber-spec-experts"
>     <amber-spec-experts-bounces at>
>     To: Brian Goetz <brian.goetz at>
>     Cc: amber-spec-experts <amber-spec-experts at>
>     Subject: [EXTERNAL] Re: Swiss Cheese Issue - Revisit?
>     Date: Wed, May 6, 2020 9:07 PM
>     ------------------------------------------------------------------------
>         *De: *"Remi Forax" <forax at>
>         *À: *"Brian Goetz" <brian.goetz at>
>         *Cc: *"amber-spec-experts" <amber-spec-experts at>
>         *Envoyé: *Mercredi 6 Mai 2020 17:08:33
>         *Objet: *Re: Swiss Cheese Issue - Revisit?
>         ------------------------------------------------------------------------
>             *De: *"Brian Goetz" <brian.goetz at>
>             *À: *"Remi Forax" <forax at>
>             *Cc: *"Manoj Palat" <manoj.palat at>,
>             "amber-spec-experts" <amber-spec-experts at>
>             *Envoyé: *Mercredi 6 Mai 2020 16:41:33
>             *Objet: *Re: Swiss Cheese Issue - Revisit?
>             I think I get what you are saying, but we didn't go out of
>             our way to _support_ it, we chose _not_ to go out of our
>             way to _disallow_ it.  So it's not like we added a
>             feature, as much as didn't disable an interaction.
>             Could you clarify what you mean?
>         The pattern variable can be supported only in expression, we
>         made an extra step to support it in the statement block
>         following the expression, to extend the instanceof so the
>         pattern variable go out of the scope the expression to the a
>         part of the scope of an 'if' or 'while'.
>     my fear is that in the end, when we have pattern matching, "if
>     instanceof" will always be seen as a poor's man pattern matching,
>     which it is, so nobody will use it so extending "if instanceof"
>     makes little sense.
>     Rémi
>         Rémi
>             On 5/6/2020 10:21 AM, Remi Forax wrote:
>                 I would like to add that the Swiss Cheese problem is
>                 specific to instanceof, it's not a pattern matching
>                 issue per se.
>                 So there is another far easier solution to the Swiss
>                 Cheese problem, don't support it because instanceof
>                 will be less prominent in the future and instanceof in
>                 equals() can be re-written to avoid the Swiss Cheese.
>                 I'm afraid we have gone a step too far by trying to
>                 support it.
>                 Rémi
>                 ------------------------------------------------------------------------
>                     *De: *"Brian Goetz" <brian.goetz at>
>                     <mailto:brian.goetz at>
>                     *À: *"Manoj Palat" <manoj.palat at>
>                     <mailto:manoj.palat at>,
>                     "amber-spec-experts"
>                     <amber-spec-experts at>
>                     <mailto:amber-spec-experts at>
>                     *Envoyé: *Mercredi 6 Mai 2020 15:02:13
>                     *Objet: *Re: Swiss Cheese Issue - Revisit?
>                     We experimented with a "cheese shield" approach:
>                      - compute the scope(s) of a binding variable as a
>                     set of position ranges: s0..e0, s1..e1, ...
>                      - compute the maximal scope for each variable:
>                     min(s0, s1, ...) .. max(e0, e1, ...)
>                      - treat the gaps as implicitly shadowing fields
>                     of the same name with an erroneous local
>                     If implementing the flow scoping is hard, I would
>                     think implementing the shielded flow scoping is
>                     harder.  The reason is that, while we might think
>                     that there is a "natural rectangular scope" for a
>                     binding, there really isn't.  So the shield gives
>                     you _two_ kinds of irregularly-scoped things.
>                     But, design decisions should put the user first. 
>                     So the question is, whether the users are served
>                     better by:
>                      - having fragmented scopes, through which light
>                     can shine, or
>                      - patching the holes so you cannot access the
>                     fields without qualification, even though the
>                     corresponding binding variable is "out of scope"
>                     And, it was really not clear which was the lesser
>                     of evils here.  There was some concern raised that
>                     this seemed scarier than it really is because it
>                     is "new and different", but not intrinsically bad.
>                     On 5/6/2020 5:28 AM, Manoj Palat wrote:
>                         Hi Brian, Gavin, all,
>                         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:
>                         "swiss cheese" is hard for implementation by
>                         compiler(atleast ecj) and understanding by
>                         users alike. For conflicts *within a local
>                         scope* tools and users can use a structural
>                         strategy to find the nearest candidate
>                         declaration to which any name reference should
>                         resolve, deferring to flow analysis only the
>                         question, whether that resolution is legal.
>                         This is not true for fields, where no
>                         structural 'proximity' applies.
>                         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.
>                         [1
>                         [2]
>                         _
>                         Regards,
>                         Manoj
>                         Eclipse Java Dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the amber-spec-experts mailing list