implicit constructor translation?

[Dan Heidinga]

On Thu, Jun 1, 2023 at 1:59 PM Brian Goetz <brian.goetz at oracle.com> wrote:

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

I'm slightly concerned about having a Code attribute for the implicit
constructor as it allows agents (ClassFile load hook & redefinition) to
modify the bytecodes to be inconsistent with the VM's behaviour given the
VM won't actually call the implicit constructor.

Telling users it's "as if" the VM called the implicit ctor and then having
the reflective behaviour be different after retransformation is slightly
uncomfortable.

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

Agreed on this.

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

And this sounds right to me as well.  I guess the only concern I have is
whether there should be a Code attribute or not and I think I lean towards
not...

>
> 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-experts/attachments/20230601/fbab6014/attachment-0001.htm>