<div dir="auto">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:<div dir="auto"><br></div><div dir="auto">Pattern overload selection seems overly complex and restrictive for a limited use-case.</div><div dir="auto"> - 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?).</div><div dir="auto"> - There's no proper way to choose any particular overload without redundant `x = x;` assignments.</div><div dir="auto"> - 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.</div><div dir="auto"> - 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?</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">(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.)</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">(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)</div><div dir="auto"><br></div><div dir="auto">Other questions:</div><div dir="auto"><br></div><div dir="auto"> - Would it make sense to be able to `yield` from a `with` block to skip the rest of the block and finish evaluation?</div><div dir="auto"> - 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".</div><div dir="auto"> - 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).</div><div dir="auto"> - Probably something else that I forgot while writing this email.</div><div dir="auto"><br></div><div dir="auto">Thank you for you time and consideration.</div><div dir="auto"></div></div>