Updated specs for Value Classes

[Dan Smith]

On Sep 29, 2025, at 11:21 PM, Remi Forax <forax at univ-mlv.fr> wrote:

- Instance fields can be both written and read in early construction

Hello Dan,
this one seems too clever for me.

I find that it make it hard to explain how things work apart from explaining the cleverness.
First, even without this feature, the fact that this.x = x is allowed but not IO.println(this)
is already a challenged to explain correctly.

Now, we can write IO.println(this.x) but still not IO.println(this),
I do not know how to explain that without explaining the trick the compiler does.

Sounds like your concern is particularly to do with 'this'? So if these were unqualified field refs, it wouldn't be so confusing?

(Aside: this reminds me that I didn't address 15.8.3, need to adjust the rule for 'this.x' expressions!)

The rule is, basically: in the early construction phase of an object, you can use the fields, but not 'this' or its methods, because the object isn't safe for sharing yet. I would not try to explain this in terms of proxy locals.

And then once somebody gets that basic rule, you can clarify the fine print:

- Inherited fields can't be accessed, have to let the superclass initialize them

- 'this.x' is just an alternate way to reference a field 'x', but the compiler understands that it's a field ref, not a generalized use of 'this' (building on the precedent of DA/DU and field initializer restrictions)

- Lambdas and inner classes capture 'this' to get to fields, so that *does* qualify as a generalized, illegal use of 'this'

For me, we are going a step too far here, yes it's convenient but it makes the semantics is more blurry.

If we were to roll back to disallowing field references entirely in early construction, I would agree that is a cleaner bright line. It would undermine our mechanism for value class creation, but it would be a less complex restriction.

But our choice here isn't about doing that, it's about allowing field refs on the LHS of assignments, or everywhere. The LHS of assignment approach still requires you to explain all the fine print rules I listed above. It just adds *another* restriction. Between those two (field ref must be LHS of assignment vs. field ref can be allowed in any form of expression if it conforms to the other restrictions), I find removing the LHS restriction to be a *simplifying* move.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-experts/attachments/20250930/410b0301/attachment-0001.htm>