<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body><div style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;">
<p dir="auto">Thank you; I prefer going to simplest possible ordering rules,<br>
if I understand this question. (It’s possible I’m missing a point.)</p>
<p dir="auto">I think the simplest rule is the direct conjunction of two<br>
independent rules: (a) do not make backwards textual references<br>
among initializers, and (b) enforce the new DA rules when those<br>
initializers are folded into the constructor.</p>
<p dir="auto">IIUC some “more expressive” rules can attempt to split the set<br>
of non-static fields into two “buckets”, strict and non-strict,<br>
and enforce textual ordering rules only within one “bucket”.</p>
<p dir="auto">Note also that static fields would also need to be split into<br>
two buckets in a parallel way. In fact, the ordering rules<br>
already (pre-Valhalla) apply to two buckets: non-static and<br>
static. The “more expressive” rules give us four buckets.<br>
I found it hard enough to learn to navigate the two-bucket<br>
restrictions, as a young Java programmer. Four buckets<br>
would have been a steeper hurdle to get across.</p>
<p dir="auto">One other observation: Field initializers are much more<br>
useful for statics than for non-statics, since one field<br>
init doesn’t always map cleanly to many non-static field<br>
instances, but it does usually map cleanly to a unique<br>
static field instance. Thus, adding complexity to gain<br>
expressiveness mainly affects statics; the complexity<br>
will be there but not beneficial to non-static fields.<br>
And even then, the extra expressiveness of being able<br>
to write your static (or non-static) fields in more<br>
orders (not all orders, just “more” orders) is not a<br>
very big gift to programmers.</p>
<p dir="auto">All Java programmers have learned to sort their fields<br>
in response to occasional snarking from javac. Whether<br>
there are two or four buckets, they will continue to<br>
do so. The four buckets would be perceived as excess<br>
fussiness with little upside, I think.</p>
<p dir="auto">HTH</p>
<p dir="auto">On 7 Nov 2024, at 12:36, Dan Smith wrote:</p>
</div><div class="plaintext" style="white-space: normal;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;"><p dir="auto">I've been looking with Vicente and Ella at the rules for forward references in field/block initializers. I originally specified it in the JEP 401 language spec to maximize expressiveness, but I'm now thinking we'd be better off sticking with the current left-to-right treatment.</p>
<p dir="auto">Here's a test:</p>
<p dir="auto">value class ValueTest {
<br>
{ System.out.println(x); }
<br>
int x = "abc".length();
<br>
}</p>
<p dir="auto">The JEP 401 spec rules say this is allowed, because 'x' has an early initializer, and the block executes late. That is, the <init> method looks like:</p>
<p dir="auto">x = "abc".length();
<br>
super();
<br>
{ System.out.println(x); }</p>
<p dir="auto">This could also manifest with null-restricted types:</p>
<p dir="auto">class NullTest {
<br>
int x = y.length();
<br>
String! y = "abc".substring(1);
<br>
}</p>
<p dir="auto">Which might compile to:</p>
<p dir="auto">y = "abc".substring(1);
<br>
super();
<br>
x = y.length();</p>
<p dir="auto">Note that we could actually do something similar with constant fields today, because constant fields are initialized before anything else:</p>
<p dir="auto">class StaticTest {
<br>
static int x = y.length();
<br>
static final String y = "abc";
<br>
}</p>
<p dir="auto">But we don't: the rule simply says that forward references are illegal, regardless of the timing of initialization at run time.</p>
<p dir="auto">Reflecting on this, I think all of ValueTest, NullTest, and StaticTest should be errors.</p>
<br></blockquote></div>
<div class="markdown" style="white-space: normal;">
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;">
<p dir="auto">I like that, under the existing left-to-right rule, a reader can make sense of the initialization code, <em>as if</em> it were all run at once, left to right. In the rare cases that timing/side effects matter, a more sophisticated reader would need to understand that some initializers run early, and others run late. But because of the restrictions on early construction code (no field reads), we can leave the left-to-right reading as "good enough" for most developers, and stick with language rules that reinforce this.</p>
</blockquote>
</div></div></body>
</html>