Draft JEP: Derived Record Creation (Preview)

[Brian Goetz]

>     Any assignment statements that occur within the transformation
>     block have the following constraint: If the left-hand side of the
>     assignment is an unqualified name, that name must be either (i)
>     the name of a local component variable, or (ii) the name of a
>     local variable that is declared explicitly in the transformation
>     block.
>
>
> And because there's no way to qualify a local variable from the 
> surrounding scope, reassigning such variables is simply impossible 
> within this block. Right?
>
> That's "no great loss" of course, although I'm missing why the 
> restriction is necessary. The notion of variables that (at least in 
> userspeak) are "in scope for reading but not for writing" seems weird; 
> does it have precedent?

There is some precedent with lambdas/inner classes, where you can only 
access effectively final locals, though that wasn't really in our mind 
when we crafted this restriction.

The motivation for the restriction is twofold:

  - This is a functional idiom (think "state monad"), side-effecting the 
environment would be weird.  (Of course, you could launder side-effects 
through any of the usual means, including probably using a qualified 
acess (Foo.x = 3; this.y = 4), but you shouldn't.)

  - We intend to extend this to classes in the future.  This idiom is 
basically "take apart with deconstructor + transform state + reconstruct 
with constructor".  There's an overload selection problem buried in 
there, and the names of variables involved in the transform may be 
important inputs to that selection decision.

We're not sure that we'll want to do overload selection nominally in 
this manner, but we're not ready to say "we will never be able to"; 
having this restriction in place keeps the flexibility to do so.

>
>     The transformation block need only express the parts of the state
>     being modified. If the transformation block is empty then the
>     result of the derived instance creation expression is a copy of
>     the value of the origin expression (the expression on the
>     left-hand side).
>
>
> This could be interpreted as saying that in this case the record's 
> constructor isn't even run, which I suspect isn't what you mean, and 
> which could make a difference (if best practices aren't being 
> followed). Do you need to say anything at all about this case?

I interpret this question as "is the result guaranteed to have a 
distinct identity from the origin expression."  (Obviously, for value 
types, the answer is "huh, what's identity?")  But we probably do want 
to say that the constructor is always invoked to produce the result, 
even if the block is empty; that "copy" is more of an analogy.

>
> Overall, there have been several references here to the record class 
> R, but I would think it's the record /type/ we really need to talk 
> about. That type post-substitution is what determines these variable 
> types, no?

Yes.  It is probably a little more complicated than "the static type of 
the origin expression is the static type of the with expression", 
because of, as you say, wildcards (and other weirdo types).  You 
probably have to do an upward projection on the type of the origin 
expression, or something like that.

>     The use of a derived instance creation expression:
>     can be thought of a switch expression:
>
>
> imho this would be useful to state earlier!
>
> What goes wrong if we think of this feature as /exactly/ desugaring to 
> that switch code?

The set of statements permissible in the two contexts is probably 
slightly different; you can do a `yield <expression>` in the RHS of a 
switch case, but not in a reconstruction block.  Probably other subtle 
reasons too.  Our experience with "specify by syntactic expansion" 
frequently runs into annoying roadblocks because of things that are 
expressible in one context but not in the desugared context, or vice versa.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20240302/4948d318/attachment-0001.htm>