Deconstruction patterns

[Remi Forax]

----- Original Message -----
> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Sent: Monday, March 6, 2023 7:24:54 PM
> Subject: Deconstruction patterns

> Time to look ahead to the next installment of pattern matching:
> deconstruction patterns, which generalize record patterns.  This
> document does an end-to-end walkthrough (at a sketchy level of detail)
> through declaration, overloading, use, translation, and reflection of
> deconstruction patterns.
> 
> I would like to *not* discuss syntax at this time.  There's a lengthy
> discussion to be had about syntax, and we'll have that, but let's nail
> down model, semantics, and translation first.
> 
> As usual, I would prefer that people either (a) post a single reply
> addressing the totality of this sketch or (b) start _new threads_ if you
> want to discuss a specific aspect.  A quick "I'll just reply to this
> minor detail" seems to often derail the conversation in such a way that
> it never comes back.  If this all looks fine to you, a quick "no
> surprises here" will keep us from suspensefully waiting for feedback.
> 
> 
> # Deconstruction patterns -- translation, use, and reflection
> 
> As we are wrapping up record patterns, it's time to look ahead to the
> next major
> part of the pattern matching story -- extending the capabilities of record
> patterns to all classes that want to support destructuring. Record
> patterns are
> simply a special case of _deconstruction patterns_ or _deconstructors_,
> where we
> derive the deconstructor API, implementation, and use from the state
> description
> of the record.  For an arbitrary class, a deconstruction patterns will
> require
> an explicit member declaration, with a header identifying the names and
> types of
> the bindings and a body that extracts the bindings from the representation.
> 
> ## Deconstructors
> 
> Just as constructors are special cases of methods, deconstruction
> patterns are
> special cases of a more general notion of declared pattern, which also
> includes
> static matchers (the dual of static methods) and instance matchers (the
> dual of
> instance methods.)  Specifically, unlike the more general notion of
> matcher, a
> deconstructor must be _total_; it must always match.  This document will
> focus
> exclusively on deconstructors, and we'll come back to static and instance
> matchers in due time.  (But note that some of the design choices in the
> simple
> case of deconstructors may be constrained by the more general case.)
> 
> There are a number of choices for how we might syntactically represent a
> deconstructor (or more generally, a declared pattern.)  For purposes of
> illustration, this document picks one possible syntactic expression of
> deconstructors, but it is premature to devolve into a syntax discussion
> at this
> time.
> 
> ```
> class Point {
>     final double x, y;
> 
>     public Point(double x, double y) {
>         this.x = x;
>         this.y = y;
>     }
> 
>     public matcher Point(double x, double y) {
>         x = this.x;
>         y = this.y;
>     }
> }
> ```

Can we discuss about the semantics of this syntax, given that it has an effect on the translation ?

By example if the matcher method is written that way (x and y are swapped)

  public matcher Point(double x, double y) {
    y = this.y;
    x = this.x;
  }

does it means that the translation should be more something like

final synthetic Object Point$MANGLE() {
  aload_0
  getfield Point::y
  dstore 1
  aload_0
  getfield Point::x
  dstore 3
  LDC #101
  dload3
  dload1
  invokevirtual MethodHandle::invoke(II)V
  areturn
}

so if there are side effects in the expressions that are initializing the local x and the local y, there are performed in the right order ?

regards,
Rémi