implicit constructor translation?

[Brian Goetz]

I think that there should be an explicit (and not synthetic) method_info 
for the implicit constructor, with the obvious Code attribute 
(`defaultvalue` / `areturn`.)

My rationale is: "the declaration said there's a no-arg constructor, I 
should be able to call it".  And that intuition is entirely reasonable.  
Users should be able to say `new Complex()` and get a default complex 
value.  (Maybe they can also say `Complex.default`; maybe we won't need 
that.)  And the same for reflection.

Also, in case it is not obvious, the following class is illegal:

     value class X {
         implicit X();
         X() { ... }
     }

because it is trying to declare the same constructor twice.  An implicit 
constructor is a constructor, just one for which the compiler can deduce 
specific known semantics.

On 6/1/2023 10:47 AM, Dan Heidinga wrote:
> Pulling on a couple of threads to make sure I have the translation 
> strategy for the implicit constructors straight.
>
> Given a class like Complex with an implicit constructor:
> ```
> value class Complex {
>     private int re;
>     private int im;
>
>     public implicit Complex();
>     public Complex(int re, int im) { ... }
>
>     ...
> }
> ```
> and the JEP 401's ImplicitCreation attribute:
> ```
> ImplicitCreation_attribute {
>     u2 attribute_name_index;
>     u4 attribute_length;
>     u2 implicit_creation_flags;
> }
> ```
> The "obvious" translation is to generate an ImplicitCreation attribute 
> if there is an implicit constructor, which seems reasonable.
>
> The piece I'm looking for clarification on is whether there will also 
> be a `method_info` in the classfile representing the implicit constructor.
>
> If the implicit constructor has a `method_info` then it will naturally 
> be represented in the same way as the explicit `Complex(int, int)` 
> constructor.  This means both will be found by reflective operations 
> (ie by j.l.Class::getConstructor) without special casing.  Users that 
> expect two constructors will find them in classfile and reflectively.
>
> Alas representing implicit constructors with a `method_info` is not 
> without costs: primarily specing how the method_info exists and 
> explaining why it doesn't have a code attribute.
>
> I know this has been mentioned on the EG calls, and I don't recall a 
> final decision or see it in the spec drafts / documents so far.  Was a 
> conclusion reached on how to do the translation?
>
> --Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20230601/51704b8c/attachment.htm>