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

[forax at univ-mlv.fr]

----- Original Message -----
> From: "daniel smith" <daniel.smith at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Sent: Saturday, October 21, 2023 8:58:58 PM
> Subject: Re: Implicit constructor of the super class of a null restricted value class

Hello Daniel,
I was agreeing with you until this morning shower ...

>> 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.

It depends if the class is abstract or not.
Do we allow a value class to extends a non-abstract class, like Timestamp inherits from Date ?

> 
> - 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.

You have forgotten that "sealed" requires that the permittted subclasses have a stable name, for example, you can not use sealed if one of the permitted subclass is local to a method.
Sealed is not a replacement for the constructor accessibility.
 
> 
> 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.

yes,
the attribute ImplicitCreation should to be extended to

ImplicitCreation_attribute {
    u2 attribute_name_index;
    u4 attribute_length;
    u2 access_flags;      // <-- add an access flag here
} 


> 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.)
> 

regards,
Rémi