<div dir="ltr">Hi,<div><br></div><div>I think the key idea is that the zero instance of an implicitly constructible class is an initialized object. In the future, when ! is extended to other classes then the object must be explicitly instantiated to be able to be assigned to a ! type, hence the name implicit constructor.</div><div><br></div><div>Regards,</div><div>Quan Anh</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 21 Jan 2024 at 04:34, David Alayachew <<a href="mailto:davidalayachew@gmail.com">davidalayachew@gmail.com</a>> wrote:<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 dir="ltr"><div class="gmail_default" style="font-family:monospace">Hello Brian,</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Just wanted to ask about this point below.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">> These two examples (conveniently, from the same package)<br>> tell us a truth about modeling data with value objects:<br>> some classes have reasonable defaults (and we can exploit<br>> this to optimize their treatment, and can freely let<br>> people use uninitialized variables, as we do for<br>> primitives today), and some do not (and hence we need<br>> either to engage nullability, or work very hard to ensure<br>> that an object cannot possibly be used uninitialized.<br><br>Oh woah, what does it look like to prevent an object to be used uninitialized? We don't have any compiler-enforced ways of doing this, right? You are talking about just manually code reviewing each use of the class to try and hope to catch any misuse?</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">And if you mean manual review, is that really something that would be worth the effort? Aside from the most trivial situations, I can't think of an example.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Thank you for your time and help!</div><div class="gmail_default" style="font-family:monospace">David Alayachew<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 20, 2024 at 2:23 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Forgot to address this part.<br>
<br>
On 1/20/2024 2:00 AM, Smith Wilson wrote:<br>
> It could solve problems with such classes like LocalDate which require <br>
> more special zeroInstance (1970-1-1) than value with pure defaults.<br>
<br>
The key thing to realize about LocalDate is that while it is a good <br>
candidate for being a value type, there is *literally no* good default <br>
value.  Jan 1 1970 is not a good default value, as we've all seen by <br>
getting emails that tell us our subscriptions are going to expire 54 <br>
years ago.  No other specific date is a good default either.  This is a <br>
statement about the _domain_; there is no good default.  (And when an <br>
abstraction does not have a good default, null is your friend.)<br>
<br>
Other classes have good defaults; Duration is such an example.<br>
<br>
These two examples (conveniently, from the same package) tell us a truth <br>
about modeling data with value objects: some classes have reasonable <br>
defaults (and we can exploit this to optimize their treatment, and can <br>
freely let people use uninitialized variables, as we do for primitives <br>
today), and some do not (and hence we need either to engage nullability, <br>
or work very hard to ensure that an object cannot possibly be used <br>
uninitialized.<br>
<br>
The reason that "implicit constructor" is a thing is that, even after <br>
we've identified that a class is a value class, we still have to <br>
identify something else: whether it is implicitly constructible or <br>
requires explicit construction.  (There's other ways to frame it, of <br>
course, but the key is that this has to be in the programming model.)<br>
</blockquote></div>
</blockquote></div>