Loosening requirements for super() invocation

[Archie Cobbs]

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

> Not sure what you mean; the spec is the language, and the language is the
> spec.  Many things that seem simple when describing them in terms of "use
> DA/DU to ..." or "use inference to ..." turn out to be complicated to
> specify -- which means the language changes are more complicated than they
> first seemed.  Gauging the spec impact is how we keep ourselves honest
> about the scope of language changes.
>


> This is obviously doable, but my recent comments (having looked at what
> the spec impact would be) is saying that this is a more complicated, more
> invasive language feature than the simpler "statements before super"
> feature.  Part of what I'm trying to do here is steer towards success by
> pruning the problem to one that can be achieved without spending years
> immersing yourself in specification.
>

Fair enough...

I guess what I meant is that I'm surprised by the notion that this change
would present a major problem in terms of updating the spec. The changes we
want to make are clear (at least, they seem reasonably clear for this point
in the process) so it's just a matter of articulating them precisely and
unambiguously. Yes, I'm sure this will be tedious, but it shouldn't be
overwhelmingly difficult. Heck if you point me at the JLS source code, I'll
be happy to take a novice stab at it.

For sure, all things being equal, a simpler language change means a simpler
task updating the spec. But I'd still like to better understand how it
might be possible to achieve the original goal.

To that end, what are the problems with the plan outlined in the previous
email?

Similarly, you'll need a way to restate the "if it doesn't start with
> `this/super`, you get an implicit super" to the more flexible notion being
> outlined here.  This is tricky because the obvious way to do this is to run
> DA/DU on the explicit body of the constructor and ask if `this` is DA at
> all points where the constructor could complete normally, and if not,
> prepend a super() call and rerun DA/DU.  This moves us from a strictly
> syntactic rule to one that appeals to a complex analysis.
>

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.

Thanks,
-Archie

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