B3, default values, and implicit initialization

[Gernot Neppert]

Am Di., 28. März 2023 um 23:10 Uhr schrieb Remi Forax <forax at univ-mlv.fr>:

>
> ------------------------------
>
> For me, the notion of default value is clearly better than the notion of
> optional constructor.
> It also works well with the idea of being able to get the default value of
> a type variable (T.default).
>
> I also really like the idea that the value class semantics is defined in
> terms of giving up properties even if it is equivalent to getting the VM
> more leeway.
>
> I fear that in term of syntax we need a little more ceremony because the
> default constructor may be buried deeply inside the class, far from the
> declaration of the value class, making the semantics of the class non
> obvious for readers. I believe, the class should declare a default
> constructor and should also be annotated with a keyword, a kind of belt and
> suspender approach.
> Or perhaps we can use the "functional interface"/"override" playbook here
> and not add a new keyword on value class but introduce an annotation
> similar to @FunctionalInterface/@Override, let say @DefaultValue (or
> whatever suits better) that documents that there is a default constructor
> thus a default value.
> If this annotation is set on a value class, the compiler will verify that
> a default constructor is present.
>
>
I agree that an annotation at class-level would make the intent much
clearer than just having a default-constructor-declaration that can be hard
to spot.
(another proposal for the name: @DefaultConstructable)
Now, if that annotation is present, then the additional "default
MyClass();" declaration seems pointless, given that it has to look exactly
that way for every value-class, and that it actually does not correspond to
any generated code (especially no constructor-related code).
Another point I see: Each @DefaultConstructable value-class claims that it
is fine with being zero-initialized. To me, this also implies that having
an additional user-defined parameterless constructor (for use with by "new
MyClass()") would be at least confusing, if not outright wrong.
Thus, I suggest to specify that if the @DefaultConstructable Annotation is
present, the compiler will enforce that there is no user-defined
parameterless constructor!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20230329/f49bdffc/attachment-0001.htm>