<div dir="ltr"><div style="font-family:monospace" class="gmail_default"><br>Hello P Holder,<br><br>Thank you for posting!<br><br>I'm not part of the Amber Dev Team, just a commenter, but I have a few thoughts.<br><br>> In thinking about record destructuring it occurs to<br>> me it could be used in more places than currently<br>> proposed.<br><br>I'll start off by making the assumption that all of these examples you then provided are things that are currently not possible in Java 20. I have been playing with destructuring a lot lately, but I might have missed a few things. So, putting this disclaimer up front.<br><br>Working on that assumption, I see a lot of value in what you are describing, but I fear that there is a significant cost that is not being acknowledged in your proposal. I'll go through each one.<br><br>> One example would be in a function call:<br>> <br>> record HumanName(firstName: String, middleName: String, lastName: String) {}<br>> <br>> HumanName humanName = new HumanName(“Alice”, “Bateman”, “Chandler”);<br>> <br>> String getFormattedName(humanName: HumanName(firstName, _, lastName))<br>> {<br>> <br>>    return lastName + “, “ + firstName;<br>> <br>> }<br>> <br>> final String fmtName = getFormattedName(humanName);<br><br>You have brought an implementation detail of the class into the method signature of getFormattedName.<br><br>The purpose of a method signature is to define a method's name, its parameters, and its return type. To add things like this destructuring to the signature adds a lot of complexity. Complexity can be acceptable, but there needs to be a good reason for it being there.<br><br>I can definitely see some good reasons. Looking at the above signature, it is clear that a null HumanName will end up in some failure state for this method. Exception probably. It's also clear that middleName isn't required, so it allows me to focus my validation efforts on the fields required. This proposal definitely provides value.<br><br>However, I don't think that the value outweighs the costs here.<br><br>Most of the value I described could be achieved by both looking at the contents of the method you are calling and reading its preconditions. Yes, sometimes, the method we are looking at has no documentation and has already been compiled with no source code available. But even then, this feels like a poor solution to deal with that problem. After all, not all preconditions can be (easily or reasonably) described through deconstruction patterns. And even if they could be, you still end up with a constraint that only exists at run time. None of those preconditions exist at compile time.<br><br>But maybe I am not seeing it. Could you go into more details about the benefits that adding deconstruction patterns in the method header provides us?<br><br>> another could be in a for loop<br>> <br>> final Set<HumanName> humans = new HashSet<>();<br>> <br>> humans.add(humanName);<br>> <br>> for (final humanName: HumanName(firstName, _, lastName): humans)<br>> <br>> {<br>> <br>>    processFirstName(firstName);<br>> <br>>    processLastName(lastName);<br>> <br>>    ...<br>> <br>> }<br><br>This functionality is actually already being considered. In fact, it was briefly previewed before they pulled it back. It's written in JEP 440 that they took it out from the record patterns JEP, so that it can be delivered separately later on. So, it is on its way, just not here now. Here is a link to the JEP 440 itself -- <a href="https://openjdk.org/jeps/440">https://openjdk.org/jeps/440</a><br><br>I would also click around and view the other JEP's involving record patterns -- <a href="https://openjdk.org/jeps/0">https://openjdk.org/jeps/0</a><br><br>> or indeed in any body<br>> <br>> with humanName as HumanName(firstName, _, lastName)<br>> <br>> {<br>> <br>>    processFirstName(firstName);<br>> <br>>    processLastName(lastName);<br>> <br>>    ...<br>> <br>> }<br><br>This too is being considered. Here is a youtube video that goes into what a possible implementation of this might look like -- <a href="https://youtu.be/L6BS2F0dWXQ?t=4485">https://youtu.be/L6BS2F0dWXQ?t=4485</a><br><br>Thank you for reaching out!<br>David Alayachew</div></div>