Implicit constructor of the super class of a null restricted value class

[Dan Smith]

> On Oct 21, 2023, at 7:03 AM, forax at univ-mlv.fr wrote:
> 
> Record is an example, even if we change the constructor of Record to public, an implicit constructor of a super class does not have to be public, being visible to the value class seems enough.

Okay, so four cases:

- Existing constructor is public. Replace it with an implicit constructor.

- Existing constructor is protected. Replace it with a (public) implicit constructor. No meaningful change in accessibility.

- Existing constructor is package-access. Declaring an implicit constructor will allow more subclasses to extend it. Only other mechanism for controlling who can extend the class is 'sealed'; that may be a reasonable workaround, given that all subclasses are in the same package.

- Existing constructor is private. Same as package-access, except 'sealed' is even easier, since the 'permits' clause can be inferred.

So, yes, there's a meaningful change in the package-access/private case.

The trade-off for supporting limited constructor access is that the VM would have to work harder to validate it: as described currently, ImplicitCreation is a boolean flag. If access could be restricted, the access level would have to appear in the ImplicitCreation attribute and be enforced at class loading. Otherwise:

abstract class Sup {
   private implicit Sup();
}

value class Sub extends Sup {
   public implicit Sub();
}

Sup s = (new Sub![1])[0]; // oops

(Compile Sup with a public constructor first, then recompile with private access.)

I don't think these use cases are worth the extra validation cost. 'sealed' seems like a reasonable workaround.