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
