Forward references in initializers

[Maurizio Cimadamore]

Having a class-wide feature would certainly help. If a class is strict, 
I can imagine us explaing to developers how their long-held assumption 
of when are things “really initialized” needs some tweaks. But if a 
class allows strict and non-strict fields to co-exist, I can imagine a 
lot of confusion to arise as a result.

E.g.

|class Test { strict int x = 1; int y = x; // ok int z = 2; strict w = 
z; // error } |

Field initialization order is already fairly complex as it is (I mean 
remembering where a field initializer is effectively expanded into by 
the compiler). Adding new rules in this area is going to increase 
complexity. But if the new rules are confined to “a new kind of class” 
(as Brian suggests) then it is (subjectively) more manageable.

Maurizio

On 11/11/2024 12:54, Brian Goetz wrote:

> I will reiterate my point that I think changing these rules is 
> something that is more amenable to a strict class, then to a subset of 
> the fields being strict. I continue to think that we are missing an 
> abstraction here.
>
> Sent from my iPad
>
>> On Nov 11, 2024, at 7:06 AM, Maurizio Cimadamore 
>> <maurizio.cimadamore at oracle.com> wrote:
>>
>> 
>>
>> I agree with this conclusion.
>>
>> The main point here is that whether strict fields are initialized 
>> before/after a super call is a very low-level detail that we'd like 
>> most developers to happily ignore. But if the distinction surfaces up 
>> at the level of DA/DU and field assignment, this is no longer 
>> strictly true, and it is possible that some developers might be 
>> puzzled as a result, and have to dig much deeper than they'd 
>> comfortable with to find exactly why that is the case. Preserving the 
>> illusion that all fields are created equal seems kind of nice, even 
>> though it is still an illusion.
>>
>> Maurizio
>>
>>
>> On 08/11/2024 19:59, Dan Smith wrote:
>>> Conclusion: I think I'm happy with a DA/DU analysis that treats
>>> initializers as if they run in left-to-right order, before the start of
>>> the constructor. It's not really true, but it detects the errors we need
>>>   to detect with less complexity.

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-experts/attachments/20241111/6b7b353e/attachment-0001.htm>