<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="line-break:after-white-space"><div style="font-family:Helvetica,Arial;font-size:13px"><div style="margin:0px">Hi Brian - thanks for the clear response.</div><div><br></div><div><blockquote type="cite" class="clean_bq"><font size="4" face="monospace">This is a nice idea, and it has come around several times in the design discussions. >From a the-system-stops-at-the-source-code perspective, it seems fine; you declare a constructor to make "the default value", and arrange that this constructor is only ever called once (during class preparation, most likely), to initialize the "stamp". Then you use the stamp to stamp out default values. Easy, right?</font></blockquote></div></div><div style="font-family:Helvetica,Arial;font-size:13px"><br></div><div style="font-family:Helvetica,Arial;font-size:13px">Understood, and I remember the debates along these lines. But what I’m hoping to suggest - maybe it’s simplistic - is to in no way change how the language/VM implement this feature, but ‘just' describe it differently without introducing a new concept (‘implicit') to the poor developer. Eliminating a keyword and an idea.</div><div style="font-family:Helvetica,Arial;font-size:13px"> </div><div style="font-family:Helvetica,Arial;font-size:13px">So my (probably simplistic) reaction is: how visible is the mechanism for initialising a field or array (to most developers)? Couldn't the language spec cover its tracks by saying notionally variables are initialised from Point.default, but the VM has discretion to use a different mechanism, and the spec would specify integrity invariants etc. that are needed (and in practice couldn’t be achieved by literally stamping with Point.default). So the language syntax, and the ‘basic idea’ in the developer’s head, are simple but with footnotes for experts. Hand-wavy I know, but maybe a spec description like that is possible, or maybe it would just be distasteful?!</div> <br> <div>best wishes,<div>Jonathan Finn</div><div><br></div></div><div class="gmail_signature"></div> <br><p class="airmail_on">On 20 January 2024 at 20:48:21, Brian Goetz (<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>
<font size="4" face="monospace">This is a nice idea, and it has come
around several times in the design discussions. From a
the-system-stops-at-the-source-code perspective, it seems fine;
you declare a constructor to make "the default value", and arrange
that this constructor is only ever called once (during class
preparation, most likely), to initialize the "stamp". Then you
use the stamp to stamp out default values. Easy, right?<br>
<br>
The only problem with this is that it is on a collision course
with VM physics. Many of the integrity invariants, as well as
many optimizations, are built on the assumption that
initialization of a new object or array is always done with the
zero-colored paint roller. If you want it done by stamps, that
means not only do you have a stamp for Point, but you also need a
bigger stamp for everything that has a Point flattened into it,
and you have much more data motion for every object
initialization. And initializing arrays means N individual
stampings, rather than just a broad stroke with the zero roller --
even more data motion. Plus, there is more room for races, and
therefore more work to prevent such races, when initializing by
copying from an exemplar than initializing with bzero. And given
that performance is a primary motivation for value classes, adding
cost to initializing values would really have to pay off big to
carry its weight. <br>
<br>
But the problem doesn't stop there, because some value classes
simply have no good default, whether it is a physical zero or
not. LocalDate is an example of such a class. <br>
<br>
So after considering this multiple times, our conclusion is that
while maybe it could be done, but even if so, it only solves part
of the problem, and the cost would be unreasonably far out of line
with the benefit. <br>
<br>
</font><br>
<div class="moz-cite-prefix">On 1/20/2024 2:43 PM, Jonathan F wrote:<br>
</div>
<blockquote type="cite" cite="mid:CABR7qme2EvKYr4B7xAYKQhhAa_Sc9AAFseASFD-ydaTioZZ+sQ@mail.gmail.com">
<div style="font-family:Helvetica,Arial;font-size:13px">I know the
EG have considered pretty much everything (I’ve followed the
forums all along) but I haven’t seen this discussed yet, so here
goes.</div>
<div class="gmail_signature">
<div class="gmail_signature"><br>
</div>
<div class="gmail_signature">It seems to me the novel concept of
implicit for constructors may not be necessary, as (IMHO) it
depends on the story that’s told about how fields are
initialised. Can’t we say the following instead? For a value
class Point, if it has the implicit constructor it also has a
quasi-static field Point.default (I think that’s still the
plan). I want to say this constructor only has 2 things
special about it: it has no body, and it’s used to initialise
Point.default when the class is initialised. Later, fields and
array elements of type Point! are (notionally) initialised to
Point.default, not by calling the constructor, which seems
more like reality and like how other fields are set to null/0.
So there’s nothing implicit about the constructor itself; and
the creation of Point.default isn’t magic either, it’s like
the creation of Point.class or enum constants - ‘just one of
those things’ that happens when a class initialises.</div>
<div class="gmail_signature"><br>
</div>
<div class="gmail_signature">If that makes sense, I’d go for the
previous constructor syntax public default Point(). Meaning
simply this is the constructor used for Point.default. Or
maybe even public default-0 Point() if it’s called the ‘zero
instance’.</div>
<div class="gmail_signature"><br>
</div>
<div class="gmail_signature">As a separate but related idea:
assuming the language has Point.default, it could be better to
have syntax like Point!.default for the object, with
Point.default meaning null (as these value classes will
effectively have 2 defaults), and in general T.default for any
type, e.g. double.default. That seems useful in itself, but it
would also allow the simple explanation that a field or array
element of _any_ type T gets initialised to T.default.</div>
<div class="gmail_signature"><br>
</div>
<div class="gmail_signature">Even if that’s not workable, it
would make me uncomfortable if Point.default is non-null when
a Point field actually defaults to null!</div>
<div class="gmail_signature"><br>
</div>
<div class="gmail_signature">best wishes,</div>
<div class="gmail_signature">JF</div>
<div class="gmail_signature"><br>
</div>
</div>
</blockquote>
<br>
</div></div></span></blockquote></body></html>