> On Sep 3, 2020, at 8:37 AM, Brian Goetz <[email protected]> wrote:
>
> The "lacks a no-arg ctor" is new and interesting. I think what you're saying
> is that having an explicit no-arg ctor with an empty body is a more stable
> signal of intent than an implicit one? I can see that.
>
> Shouldn't the non-empty body one be "declares any constructor with a
> non-empty body", regardless of arity? The only reasonable thing here would
> be a side-effect (like an instance initializer) or a nontrivial super call,
> both of which seem to put you in the Identity category.
The way I wrote these rules is confusing. Let me try again.
An inline superclass must have a constructor of the form:
Foo() { super(); }
If this constructor is implicit (because the class body declares no
constructors), that's fine. I guess we could force it to be explicit, but I
think the goal here is to minimize the effort an abstract class puts into
authorizing inline subclasses. Support for inline subclasses is the default
behavior.
If the 'super()' call in an empty no-arg constructor is implicit, that's fine.
If the class body declares *other* constructors too, that's fine. When there
are multiple paths to initialize an instance, the inline subclass will always
choose the "do nothing" path.
> Still not sold on keying off the existence of a constructor with a novel
> shape at the classfile level. Seems too clever, and comes with a complex
> verification.
Yeah, I wonder if a straightforward "InlineSuperclass" attribute at the class
level is a better way to encode this. John likes the idea that the class author
explicitly says "there's no initialization to do", but I think it also works to
specify that inline subclass creation uses a separate mechanism that simply
doesn't perform initialization.
