<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Di., 28. März 2023 um 23:10 Uhr schrieb Remi Forax <<a href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><div><br></div><hr id="m_6990818833966639371zwchr"><div><br><div>For me, the notion of default value is clearly better than the notion of optional constructor.<br></div><div>It also works well with the idea of being able to get the default value of a type variable (T.default).</div><div><br></div><div>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.<br></div><div><br></div><div>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. </div><div>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.</div><div>If this annotation is set on a value class, the compiler will verify that a default constructor is present. <br></div><div><br></div></div></div></div></blockquote><div><br></div><div><font size="2">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.</font></div><div><font size="2">(another proposal for the name: <a class="gmail_plusreply" id="plusReplyChip-0">@DefaultConstructable)</a><br></font></div><div><font size="2">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).</font></div><div><font size="2">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.</font></div><div><font size="2">Thus, I suggest to specify that if the @DefaultConstructable Annotation is present, the compiler will enforce that there is no user-defined parameterless constructor!<br></font></div><div><font size="2"><br></font></div></div></div>