Imported From: https://issues.scala-lang.org/browse/SI-9836?orig=1
Reporter: @dwijnand
Affected Versions: 2.11.8
See #6675, #6111

@som-snytt said:
Maybe res0 should be (1). If you want 1, define get appropriately.

@dwijnand said:
Why? res1 isn't ((1), (a))

@som-snytt said:
res1 is a tuple, so res0 should be a tuple, too. Probably I expect to iterate over the Product elements.

Uniformity was discussed in comments to #7897

It's inconvenient to special-case Product1 just because n == 1.

@dwijnand said:
I changed the examples to use array, so we don't get all hung-up on confusing the arity of the extractor with the arity of the return type.

It returns Array(Bippy(1)) when it should return Array(1).

@dwijnand said:
Simplified the test case to Foo1(a: Int) and Foo2(a: Int, b: Int).

res0 is an Array[Foo1] where I expected it to be an Array[Int].

Tested on Dotty and the same problem exists there: https://scastie.scala-lang.org/kVbcuVRFQ7ScUjx5VehItA.

I started looking at this and the linked tickets about so-called "auto-tupling in patterns".

I think the first example below is perfectly fine and should not warn (as it currently does). I almost had a fix last week, but ExtractorAlignment sees the tree in typer and the different tree in patmat. The test is simply that the subpattern consumes the required tuple.

The code is commented "don't unwrap Tuple1", but maybe there is a useful cue for whether to unwrap, for example, Product1, or detect get = this to avoid self-extraction. I encountered the asymmetry in a macro once, where it was inconvenient to generate the special case.

object X { def unapply(s: String): Option[(Int,Int)] = { val Array(a,b) = s.split("/") ; Some((a.toInt,b.toInt)) }}
object T { def unapply(t: (Int,Int)) = Option(t._1+t._2) }

trait Test {
  "1/2" match { case X(T(x)) => x }

  "1/3" match { case X(x @ (_, _)) => x }

  "1/4" match { case X(x) => x }
}

Studying scala/scala3#15230 I realised why it's important that you can bind the result of the get in the arity-1 case.