<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>