Loosening requirements for super() invocation

[Brian Goetz]

So, its possible that #3 also has reasonable cost/benefit.  The current 
"pinch point" approach could probably be brought to bear on it with 
modifications, without having to thread everything through DA.  But I 
think there are subtleties to think through first.

For example, would this be allowed?

class A {
     final int a;

     A() { this.a = 0; }
}

class B extends A {
     B() {
         this.a = 1;
         super();
     }
}

The current draft JEP says it would:

> Add the following restrictions on constructors:
>     No access to this, other than assignments to fields, may occur 
> unless this is DA

This is clearly an "assignment to a field", but I think we can agree 
that the code above is pretty dodgy.

So what I'm proposing is to address the feature that everyone likes and 
we agree can be addressed with less fuss, and then consider coming back 
for more later.


On 1/26/2023 12:13 PM, Archie Cobbs wrote:
> On Thu, Jan 26, 2023 at 10:59 AM Brian Goetz <brian.goetz at oracle.com> 
> wrote:
>
>     As we look at the implications of this, though, we start to see
>     that the cost/risk/complexity keeps cropping up in the lower-value
>     aspects.  To summarize, here are the things you originally
>     proposed to align:
>
>      - Allowing statements before the this/super;
>      - Choosing different super/this ctors in different paths;
>      - Initializing fields prior to this being DA.
>
>
> I think we all agree on #1.
>
> I agree that #2 is "niche" and therefore should be included ONLY if 
> it's not the singular cause of a bunch of additional spec noise. 
> Personally I "believe" you (air quotes) that it would be, but also 
> want to see for myself... I'm sure you'll be proved right...  and for 
> now will leave that to others to argue.
>
> Seems like there's still some valid debate (not just from me) about #3 
> though... ?
>
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230126/7b25cc7e/attachment.htm>