Add support for Java records in patterns.

[yilinwei]

For each Java record, we create a synthetic unapply method returning a Tuple on the companion object.

I briefly toyed with the idea of adding inline methods for Product to reduce the allocation, but I don't think that would be safe. In particular, I expect the following block to be unsound if that was the case:

val x: Product = R1()
x.productArity

I would like to test this further; hopefully after #19578 is fixed.

Many thanks to @som-snytt, @SethTisue and @sjrd for the help.

There was also a suggestion from the Discord chat of a different desugaring involving extension methods and by-name pattern matching with an opaque type alias to reduce the allocations.

However we currently only check for the by name extension methods on the actual extractor objects (see Applications#extractorMember) and looking for extension methods in this case looks as though it might open a whole can of worms.

Using an AnyVal works - but I would like to verify that the byte code generated is correct.

EDIT:

The byte code looks fine in that there is no allocation of an intermediate object.

However the isEmpty isn't omitted even if the type is narrowed to false and the accessors, _1 and _2 aren't inlined either.

I'm also worried about records compiled via javac for this encoding since the method descriptors stick around in the compiled code so presumably they would need to be bundled somewhere otherwise it would fail at runtime? It's unclear to me how methods which aren't inlined on the companion module of the record would work due to my rather limited understanding of the nuances of the mixed compilation processes.

Roughly speaking, here is the encoding which I experimented with:

record Moo(x: Int, y: Int) {}

object Moo {
  inline def unapply(moo: Moo): Forward = Forward(moo)
}

final class Matcher(val moo: Moo) extends AnyVal {
  inline def _1: Int = moo.x
  inline def _2: Int = moo.y
}

final class Forward(val moo: Moo) extends AnyVal {
  def get: Matcher = Matcher(moo)
  def isEmpty: false = false
}

EDIT:

As per the discussions in #19631, we now deal with the problems in the PatternMatcher and make Java records a first class citizen of the pattern matcher.

I have a few points here and there I'd like to check, but after that I will start writing the SIP.

EDIT:

Pre-SIP is here.

[He-Pin]

This should be epic, does it support compiled records, eg the records from a jar?

[joroKr21]

Perhaps related - I wonder if we can support mirrors for records (and sealed classes)

[yilinwei]

@He-Pin It should do - I'm not entirely clear about the way Scala works with raw jars, but you can certainly call the synthesized apply methods on Java classes when they are from a jar rather than source.

@joroKr21 That is indeed the intention; there are a few other issues that I want to fix to help the record support along; like #19386 for example.

[nicolasstucki]

What is the point in inlining inline def _1: Int = moo.x? If it is for an optimization, then its better to not mark it as inline and let the JVM, Scala.js, or Native backend inline it.

[yilinwei]

@nicolasstucki

It is because I am unsure whether it is OK to let the final compiled code refer to the functions in the synthesized companion module. I do not understand where/how that code would be bundled, especially for a jar not compiled with scalac.

[sjrd]

I strongly suggest you use run tests for these things. You want to make sure that your code can actually be executed by the JVM.

[yilinwei]

This is surely too standard to need to do it by hand...

[yilinwei]

Is this going to be a big deal? It means that compiling the scala library would need JDK 16+ but could target older versions, but having this on the classpath and not loaded should not be an issue? Maybe I could exclude the source, if records are not supported but would that cause issues with the current publishing process?

[yilinwei]

This mirror is of limited use and requires the user to check the type at the derivation site for the mirrored mono type. This isn't the end of the world - we could add an extension method which uses the RecordComponent to invoke the accessor, but can we add a method to the mirror like productElement(a: A)(i: Int) which allows users which derive with the mirror to hide the implementation details?

Maybe this doesn't matter because actual practitioners would use the dotty reflect to select the field labels.

[yilinwei]

Should this transformation happen in the Typer just after we've created the unapply object instead - this would mean the pickler wouldn't see the proxy; would that be better?

[yilinwei]

We can transform the unapply into an identity function.

[Gedochao]

@yilinwei What is the status of this PR? Do you mean to work on it in the near future, or should we close it?
cc @Florian3k

[Florian3k]

I've tried the same approach in #24140 (synthetic unapply) and it was decided, that we don't want to do it this way.

[Gedochao]

Tracked under #20561 (and the linked above last attempt, #24140)
We will likely revisit the issue in Scala 3.10 series.
Closing this due to inactivity.
If you'd like to take another shot at this, please coordinate with @Florian3k