On Mar 5, 2021, at 2:41 PM, Guy Steele <guy.ste...@oracle.com> wrote:
>
>> because at the point where the pattern true(...) is evaluated, the Rectangle
>> has already been destructured, obviously, we can ban this kind of patterns
>> to try to conserve the left to right evaluation but the it will still leak
>> in a debugger, you have access to the value of 'y' before the expression
>> inside true() is called.
>
> I would like to question your assertion
>
> bindings are all populated at the same time by a deconstructor
>
> Is this really necessarily true?
Same question from me, and I hope it’s not true.
And I see Brian has also piled on here!
> I would have thought that the job of the deconstructor is to provide the
> values for the bindings, and that int principle the values are then kept in
> anonymous variables or locations while the subpatterns are processed, one by
> one, from left to right. Because consider a more complex pattern:
For records that is true. But eventually I would say that the
job of the deconstructor is simply to provide some sort of
bundle of bits which might need more “cooking” in order
to unveil the components. Then, each occurrence of a
binding variable or a sub-pattern triggers that cooking,
but a don’t-care pattern (_ or …) does *not* trigger the
cooking. Who cares when something is cooked? Well,
if a component of an object is virtualized (NOT the case
with records) then it might cost something to reify it.
As a simple example, an array component might require
that an underlying array be defensively copied.
As a more subtle example, a RE-matching pattern
might require a lot of additional “cooking” to
reify the contents of an RE expression group.
So, my model of a deconstructor, in general, is
of one operation which produces a handle of
some sort, plus N additional operations which
optionally extract the N components. Or, almost
equivalently, it is a configurable method
which produces up to N values, based on how
it is invoked. (There’s a job for indy here.)
The body of a user-defined deconstructor could
exercise all these degrees of freedom, if there
were a way to “hook up” all of the out-vars,
but also provide an “out-var-requested” flag
for each one:
class PairOfArrays {
int[] a; int[] b;
__Deconstructor(out int[] aa, out int[] bb) {
if (aa requested) aa = a.clone();
if (bb requested) bb = b.clone();
} }
Here, the set of requested variables in the pattern
affects how much work the deconstructor does.
— John
