Loosening requirements for super() invocation

[Archie Cobbs]

On Wed, Jan 25, 2023 at 2:19 PM Brian Goetz <brian.goetz at oracle.com> wrote:

>
> I'm not completely understanding this. Wouldn't it be simpler to just say
> that for any constructor in which this()/super() nowhere appears, the
> analysis starts with `this` being DA instead of DU? Or equivalently, the
> analysis proceeds as if super() were inserted as the first statement in the
> constructor.
>
>
> For example, here's a constructor that contains a `this()` call, but for
> which `this` is not DA at the end:
>
> C() {
>     if (foo)
>         this(3);
> }
>
> As it turns out, there's nothing we can do to save this constructor; we're
> going to error out due to flow issues.  But we have to do a fair amount of
> work before we can figure that out.  But the mere syntactic presence or
> absence of a super/this call is not obviously sufficient.
>
> The current rule about implicit supers is _syntactic_; we need only look
> at the parse tree and ask "was there an explicit super call", and know
> immediately whether we have to treat things as if there were a synthetic
> one, or not, before doing any analysis.  But a DA/DU-based rule means we
> have to speculatively perform linguistic analysis on the code (type
> checking, flow analysis, etc) to even determine whether this is really the
> code we want to work with in the first place, or whether we have to mangle
> it and then do it all again.  (Even this description is more a description
> of what the compiler will do; the spec doesn't talk about processing or
> type checking as a thing that happens, and so leans more heavily on things
> happening in a certain order in order for such analysis to be
> well-defined.)
>

I'm still not understanding (sorry).

The new rule for implicit supers would be syntactic as well.

The rule is this: Add an implicit super() if there are NO occurrences of
any this() or a super() anywhere in the constructor.

This is just the direct generalization of the previous version of this rule.

If there is a this()/super() on some code branch but not on another, then
do nothing. The DA/DU analysis will automatically catch the error.

Additionally, since we currently quarantine the cases where `this` is DU to
> the single explicit constructor call, we don't have to thread DA of `this`
> throughout the rest of the JLS; the generalization would likely send
> tentacles farther and wider (e.g., lambda bodies, switch expressions,
> etc.)
>

This is where I'm proposing that we borrow from the concept of "static
context". We'd say the "static context" rules apply to any statement in a
constructor where 'this' is DU, with the exception of field assignment.
This rule would just be an additional condition added on top of the
existing rules. Wouldn't that work?

-Archie

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