Loosening requirements for super() invocation

[Maurizio Cimadamore]

On 26/01/2023 18:16, Archie Cobbs wrote:
> 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...

Well, you could have a subclass (in some client jar) which "subverts" as 
you say, some superclass in a library. Perhaps the library was not 
prepared for that kind of behavior, and now there's a new bug.

IMHO, we should try to stay well clear of that can of worms. It's not 
like we have to open it now either - the other things you propose are 
100% non-controversial.

Maurizio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230126/4d9d9486/attachment.htm>