Jep 468: What about 'new' syntax?

[Olexandr Rotan]

Yea, Brian, I agree with you. I wasn't even proposing that as argument
against proposal, more like a nasty little detail, hence this is a "side
note". Moreover, if (or, I hope, when) more record features expanded to all
classes, compiler will still be required to clone non-value objects since
they can be mutable, and with implies making a copy (although not always
actually has to do it as in my example).

But I gave more thought to this today, and what I have concluded is that I
would rather vote against it. The reason is that only value that "new"
brings to the table here is better "human readability". But, for me it
seems more like a mumbling. I am, I guess, more of a writablity guy than
most people here, so I don't really like mumbling. Also it is some noise
for reader. "New" here does not help resolve some ambiguity nor for
compiler nor for reader, at least as it seems for me. That's why I would
say I am not a fan of this syntax

On Wed, Nov 20, 2024, 15:18 Brian Goetz <brian.goetz at oracle.com> wrote:

>
> > Hello. Just a side note: AFAIK "new", by spec, guarantees that new
> > instance of object is returned
> >
>
> Historically this is true.  However, when Valhalla gives us value types,
> the "new"-ness of a new value object will be indistinguishable from an
> old object.  So I would advise against taking this "new means new"
> dictum too literally.
>
> > , so it can potentially affect implementation requirements for
> > compilers, forcing them to copy records even if with expression block
> > is empty, i.e.
> >
> > var b = new a with {}
> >
> > Unless there is a exception for such syntax, new will mandate that b
> > != a (by reference)
> >
>
> ... unless a and b are value objects, in which case == compares their
> state, not their identity (because they have none.)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241120/d0404c8a/attachment.htm>