<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <font size="4"><font face="monospace">I can think of multiple
        explanations for why this wasn't done in 1.1 when the
        `MyClass.this` syntax was introduced, but I think there's a
        little more detangling to be done before we have a clear menu of
        options, because we have to consider that `Example1.this` only
        means `this` when there are no intervening class declarations
        between the use and the declaration of Example1.  <br>
        <br>
        To come up with a sensible meaning of option (2), I think we
        have to assess the spec impact of threading the equivalence of
        `[implicit C].this` and `C.this` through the spec?<br>
        <br>
        <br>
      </font></font><br>
    <div class="moz-cite-prefix">On 12/1/2022 1:09 PM, Archie Cobbs
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CANSoFxsfXBn9zxRMsKqVw1mZOjjrDjhJQwa34D+RVOEXEEo9WQ@mail.gmail.com">
      
      <div dir="ltr">
        <div>This relates to <a href="https://bugs.openjdk.org/browse/JDK-8193904" target="_blank" moz-do-not-send="true">JDK-8193904</a> (if
          amber-dev is the wrong place to ask about this please let me
          know; here's an <a href="https://mail.openjdk.org/pipermail/compiler-dev/2022-November/020899.html" target="_blank" moz-do-not-send="true">earlier thread</a> on
          compiler-dev).</div>
        <div><br>
        </div>
        <div>The bug asks the question, should we change the JLS so that
          "MyClass.this" is treated the same way as "this" with respect
          to definite assignment?</div>
        <div><br>
        </div>
        <div>Here's how the compiler currently behaves:<br>
        </div>
        <div><span style="font-family:monospace"><br>
          </span>
          <div style="margin-left:40px"><span style="font-family:monospace">// This class compiles
              without error</span><br>
            <span style="font-family:monospace">public class Example1 {</span><br>
            <span style="font-family:monospace">    final int foo;</span><br>
            <span style="font-family:monospace">    public Example1() {</span><br>
            <span style="font-family:monospace">       
              System.err.println(Example1.this.foo);  // no error
              generated here</span><br>
            <span style="font-family:monospace">        this.foo = 42;</span><br>
            <span style="font-family:monospace">    }</span><br>
            <span style="font-family:monospace">}</span><br>
            <span style="font-family:monospace"></span><br>
            <span style="font-family:monospace">// This class fails to
              compile</span><br>
            <span style="font-family:monospace">public class Example2 {</span><br>
            <span style="font-family:monospace">    private final int
              foo;</span><br>
            <span style="font-family:monospace">    public Example2() {</span><br>
            <span style="font-family:monospace">       
              Example2.this.foo = 42; // "cannot assign a value to final
              variable</span><span style="font-family:monospace"> foo"</span><br>
            <span style="font-family:monospace">    }</span><br>
            <span style="font-family:monospace">}</span></div>
        </div>
        <div><br>
        </div>
        <div>Presumably the reason for the different treatment is
          because in general the qualifying expression could be
          arbitrarily complex and the compiler can't be expected to
          detect any possible qualification in front of "foo", so why
          even start down that road?</div>
        <div><br>
        </div>
        <div>For example, instead of</div>
        <div><br>
        </div>
        <div style="margin-left:40px"><span style="font-family:monospace">Example1.this = 42;</span></div>
        <div><br>
        </div>
        <div>you could have:<br>
        </div>
        <div><br>
        </div>
        <div style="margin-left:40px"><span style="font-family:monospace">((Example1)Function.<Object>identity().apply(this)).foo
            = 42;</span></div>
        <div><br>
        </div>
        <div>Currently JLS §16 says:</div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
          0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
          <div>
            <p class="gmail-norm-static"><a name="jls-16-110" moz-do-not-send="true"></a> An access to its value
              consists of the simple name of the variable (or, for a
              field, the simple name of the field qualified by <code class="gmail-literal">this</code>) occurring anywhere in
              an expression except as the left-hand operand of the
              simple assignment operator <code class="gmail-literal">=</code>
              (<a class="gmail-xref" href="https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.26.1" title="15.26.1. Simple Assignment Operator =" moz-do-not-send="true">§15.26.1</a>). </p>
          </div>
        </blockquote>
        <div>Some options...</div>
        <div>
          <ol>
            <li>Deprecate the use of "MyClass.this" where "this" would
              work and start generating a warning</li>
            <li>Update JLS §16 to say "qualified by this or qualified by
              MyClass.this"<br>
            </li>
            <li>Do nothing and resolve JDK-8193904 as "Won't Fix"</li>
            <li>??<br>
            </li>
          </ol>
        </div>
        <div>
          <div>Thoughts?</div>
          <div><br>
          </div>
          <div>-Archie</div>
          <div><br>
          </div>
          -- <br>
          <div dir="ltr" data-smartmail="gmail_signature">Archie L.
            Cobbs<br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>