Loosening requirements for super() invocation

[Archie Cobbs]

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

>
> 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.
>
>
> So, let's look at the grammar.  Where does the production that matches
> `super(e)` come from?  Its from ConstructorBody:
>
>     ConstructorBody:
>     { [ExplicitConstructorInvocation] [BlockStatements] }
>
> If you pull on the string for BlockStatements, you'll see a whole nest of
> statement forms, *none of which match this(e) or super(e)*.  So to allow
> one of these statements inside a block, you have to refactor all the
> statement productions in the language.  Then you have to go through the
> entire spec and prohibit these in the places where they can't be used (such
> as lambdas.)
>

OK now I understand - thanks for being patient :)

I didn't realize that the restriction that super()/this() must be first in
a constructor was actually implemented using the language grammar.

But it doesn't have to be that way, does it? I mean, the grammar allows
"foobar()" to appear in any method, even when "foobar()" cannot be
resolved. The requirement for "foobar()" to be resolvable is stated
elsewhere, outside of the grammar.

So why not, in the grammar, allow super()/this() to appear anywhere that
any other method call can appear, and then layer on the restriction that
they may only appear in constructors as a separate (English) sentence?

It makes intuitive sense that we would need to do it this way because (as
the JEP describes) we're converting a syntactic requirement into a semantic
one.

-Archie

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