Evolving instance creation

[Dan Smith]

> On Feb 24, 2022, at 8:47 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> ----- Original Message -----
>> From: "Dan Heidinga" <heidinga at redhat.com>
>> To: "daniel smith" <daniel.smith at oracle.com>
>> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
>> Sent: Thursday, February 24, 2022 4:39:52 PM
>> Subject: Re: Evolving instance creation
> 
>> Repeating what I said in the EG meeting:
>> 
>> * "new" carries the mental model of allocating space.  For identity
>> objects, that's on the heap.  For values, that may just be stack space
>> / registers.  But it indicates that some kind of allocation / demand
>> for new storage has occurred.
>> 
>> * It's important that "new" returns a unique instance.  That invariant
>> has existed since Java's inception and we should be careful about
>> breaking it.  In the case of values, two identical values can't be
>> differentiated so I think we're safe to say they are unique but
>> indistinguishable as no user program can differentiate them.
> 
> Yes, it's more about == being different than "new" being different.
> 
> "new" always creates a new instance but in case of value types, == does not allow us see if the instance are different or not.

I'm not sure this is a good way to think value creation, though. It suggests that there still *is* an identity there (i.e., the new value has been newly allocated), you just can't see it.

I'd rather have programmers think in these terms: when you instantiate a value class, you might get an object that already exists. Whether there are copies of that object at different memory locations or not is irrelevant—it's still *the same object*.