Loosening requirements for super() invocation

[Archie Cobbs]

On Thu, Jan 26, 2023 at 11:00 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> I agree that the behavior you propose is not problematic per se.
>
> But, as I mentioned, it brings up can of worms. For instance, now a
> superclass constructor could see its field with a non-zero value. Which
> could definitively be surprising. After all, there might be code in the
> wild assuming that an int field that has not been assigned yet has value
> zero - whether writing code like that is good or bad, it's a separate
> question. My point here is that here you cross a fine line between  "let's
> make the language more expressive" and "this change might have some
> compatibility impact".
>
Yes, but for this to happen the subclass would have to be in effect
intentionally subverting the superclass constructor.

In other words, a problem like you describe can't suddenly just start
happening "by accident" just because this new feature exists...

As I said, my general feeling is that it's not worth going there to "fix
> escaping this" - because... developers should strive to write code where
> this doesn't escape in the first place (and hopefully the Lint warning you
> recently added will help with that).
>
That horse has already left the barn... for example a bunch of JDK classes
like HashSet.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230126/39e99bb0/attachment.htm>