> On Feb 24, 2022, at 8:47 AM, Remi Forax <fo...@univ-mlv.fr> wrote: > > ----- Original Message ----- >> From: "Dan Heidinga" <heidi...@redhat.com> >> To: "daniel smith" <daniel.sm...@oracle.com> >> Cc: "valhalla-spec-experts" <valhalla-spec-experts@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*.
