<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<blockquote type="cite" cite="mid:CAFMUOF7m=7enqHJ8ezvGb8VHDr2wGRbr+Os69QY69uZqMVuM6A@mail.gmail.com">
<div dir="ltr">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>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.<br>
</div>
</blockquote>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>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?</div>
</div>
</blockquote>
<br>
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. <br>
<br>
The motivation for the restriction is twofold:<br>
<br>
- 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.)<br>
<br>
- 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.<br>
<br>
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. <br>
<br>
<blockquote type="cite" cite="mid:CAFMUOF7m=7enqHJ8ezvGb8VHDr2wGRbr+Os69QY69uZqMVuM6A@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>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).<br>
</div>
</blockquote>
<div><br>
</div>
<div>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?</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite" cite="mid:CAFMUOF7m=7enqHJ8ezvGb8VHDr2wGRbr+Os69QY69uZqMVuM6A@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>Overall, there have been several references here to the
record class R, but I would think it's the record <i>type</i> we
really need to talk about. That type post-substitution is what
determines these variable types, no?</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite" cite="mid:CAFMUOF7m=7enqHJ8ezvGb8VHDr2wGRbr+Os69QY69uZqMVuM6A@mail.gmail.com">
<div dir="ltr">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>The use of a derived instance creation expression:<br>
can be thought of a switch expression:<br>
</div>
</blockquote>
<div><br>
</div>
<div>imho this would be useful to state earlier!</div>
<div><br>
</div>
<div>What goes wrong if we think of this feature as <i>exactly</i> desugaring
to that switch code?</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<br>
</body>
</html>