
<html><head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body>

    <br>

    <br>

    <blockquote type="cite" cite="mid:CANSoFxvfMBQrdVH9CPszy2in7zdpSb6a+RjCNmNbw7Bxr2w4Fw@mail.gmail.com">

      <div dir="ltr">

        <div>I agree the topic of "this" escaping is definitely an

          interesting one. Although there is a lot of code out there

          that currently relies on it (e.g., <span style="font-family:monospace">HashSet</span> and <span style="font-family:monospace">AbstractCollection</span>),

          perhaps someday we could realize this in a backward-compatible

          way by adding a notion of a "safe constructor" which would be

          limited to following more strict rules that disallowed "this"

          escapes.</div>

      </div>

    </blockquote>

    <br>

    So, what you're saying is that we can't immediately promote these to

    errors, but that doesn't mean we can't have warnings.  (We are

    fairly disciplined about zero-warnings in the JDK, using

    @SuppressWarnings to augment type checking with human judgment.)  <br>

    <br>

    Warnings are an important part of the safety story.  For example,

    generics are subject to heap pollution because of erasure, but we

    make a strong guarantee anyway: if the entire codebase compiles

    without raw or unchecked warnings, then the synthetic casts

    introduced by the compiler at the boundary of generic and

    non-generic code are guaranteed to succeed.  Similarly, while it is

    a high bar, if we can reliably warn about this-escape, we can make a

    similar guarantee for the final-field initialization safety

    guarantees, which are voided by this-escape.  <br>

    <br>

    <blockquote type="cite" cite="mid:CANSoFxvfMBQrdVH9CPszy2in7zdpSb6a+RjCNmNbw7Bxr2w4Fw@mail.gmail.com">

      <div dir="ltr">

        <div>So this change does not make the problem of "this" escape

          any worse than it already is. That means the two problems are

          really separate and can be addressed separately and

          independently.</div>

      </div>

    </blockquote>

    <br>

    I get where you're coming from; you have a patch that you'd like to

    see integrated, so you're trying to keep the requirements narrow. 

    But realistically, this patch surely needs a JEP, because it affects

    the language spec and the user-visible programming model.  And such

    a JEP is going to be more compelling if it addresses the

    closely-related issue of this-escape.  <br>

    <br>

    <br>

  </body>

</html>