Reconstruction expressions questions

[Izz Rainy]

First off - sorry if this is the wrong list (still a little confused
between -dev and -spec-comments for in-design features). Reconstruction
expressions sounds like a very useful feature, just a few "minor"
nitpicks/questions:

Pattern overload selection seems overly complex and restrictive for a
limited use-case.
 - It's "magic", bringing new names into context as they are requested, so
long as they match. This on its own is probably fine, but it does create
(IMO unnecessary) complications around assigning to other local variables
and using undeclared variables (can usages affect overloading?).
 - There's no proper way to choose any particular overload without
redundant `x = x;` assignments.
 - It might not work for a private-representation use-case if you only
modify variables shared with public representation & the private one is not
"maximal", but want to ensure the internal representation stays the same
for whatever reason.
 - Access control-based selection might help, but that would stray even
further from regular overload selection ("it's only used when private?"),
and at that point, why not just use access control instead of overloads at
all?

My simplest solution would be to only allow one public byname deconstructor
and one private, and use the private one when accessible/when using
`with-private` or something. My favourite solution would be to allow naming
byname deconstructors, defaulting to the maximal one and allowing
`with-<name>` for selecting a particular one, given that `private` is
possibly a valid name.

(Overload resolution does have the advantage of allowing the use of a
faster smaller deconstructor if available, but I don't know how much
speedup is possible there and whether it's worth introducing another
complex form of overloading for it. Brian mentions that avoiding an
accessor call is unlikely to have any effect, though a less-trivial
deconstructor might see more of a difference - but patterns aren't supposed
to do non-trivial work anyways, especially anything impure or observable.)

Related, JS has a similar sort of `with(x)` *statement* that brings all of
the components/fields of `x` into scope as "locals". Since JS resolves
references at runtime, and these locals take precedence over other
parameters or variables, the definition of `x` could be updated to include
new variables and change how your unchanged code runs to use random other
values of a different type, and is deprecated for that reason. Here, that
would require a recompilation and for the types to happen to be similar
enough, and we don't have methods-as-fields, but I do think that's still
likely enough to be a concern. At the least, it necessitates an "outer
scope" syntax or `let in`-ing every value to actually ensure forward
compatibility.

(Only kind of vaguely somewhat related, in my "ideal Java" you'd be able to
name constructors too, and specify a particular one in e.g. `new sized X()`
to avoid as much usage of static factories and allow constructors with the
same signature. Here, you only need the ability to possibly-name
deconstructors though. Perhaps named constructors could help in overload
resolution for constructors with default parameter values? lol)

Other questions:

 - Would it make sense to be able to `yield` from a `with` block to skip
the rest of the block and finish evaluation?
 - Very minor, but having an explicit form for cloning from now would be
useful to avoid `x with {}`, which looks like a no-op and is confusing if
you don't know the underlying goings-on of `with`, from becoming a
best-practice "free" clone function. Maybe being able to generate `clone`
bodies from deconstructors down the line, maybe a syntax like `x with _` or
`x cloned` (bad strawmen) would work, just not a "no-op".
 - Would it make sense to (at some point) have `with` for arrays? Say, `x
with { [0] = 1; }`? Given array patterns, it would complete the circle of
"breaking down and putting back together with identical syntax" (yes that's
not the proper wording but it's the general idea).
 - Probably something else that I forgot while writing this email.

Thank you for you time and consideration.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20220614/5c94e3c6/attachment-0001.htm>