The block is also special because there is an implicit return at the
end ? so i believe "return" should be disallowed inside the block, right ?
That's a good question; we can go in multiple directions with this. One
would be to simply interpret "return" as "return from the enclosing
method". We confronted this with the blocks on the RHS of -> in switch
expressions, and decided to disallow return there; that's probably a
good default choice here too.
Does the lifting that appears at the beginning of the block call all
accessors ? or the compiler try to be clever and not call an accessor
when its value is not needed.
There's several reasons to just call them all, the biggest of which is
that the accessors are incidental; really, there's a synthetic
deconstruction pattern in the record, whose implementation just may
delegate to accessors. There is little semantic or performance benefit
to not calling them (there shouldn't be side effects in accessors
anyway, and the JIT will likely inline the calls away and see that
unneeded fetches are dead anyway.)
For example, in
point with { y = 3; }
calling point.y() is useless, or is it something the JIT will take
care of ?
For an ordinary record, the accessor is a field access, it will get
inlined, and the fetch will be dead. So, yes.
Do we allow "with" followed by an empty block ? As a way to clone a
record ?
Yes. The RHS is just a block of Java. If it does nothing, it does
nothing. Free cloning.
About the declaration of local variables, in Java, there is no
hiding/shadowing between local variables, so a code like this is
rejected ? Or do we introduce a special rule for the hiding of
implicit variables ?
Yes, we probably do need a special rule for this. The component names
are fixed, and collisions are likely, so these synthetic variables will
probably have to be allowed to shadow other locals.
yes, Complex.default with { re = 3; im = 4; } seems a great fit for
value classes.
Or even better:
value class Complex {
...
Complex conj() -> this with { im = -im; }
}
