Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix #11008: Support generic tuples as a valid unapply result #14434

Merged
merged 3 commits into from
Feb 14, 2022

Conversation

anatoliykmetyuk
Copy link
Contributor

On top #14296.

Done during the Issue Spree of 8th February together with @dwijnand and @prolativ

apply(x :: accum, x2)
case x => foldOver(accum, x)
end tupleFold
tupleFold(Nil, tp).reverse
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I overshot by thinking we should do a fold here. I think that's the cause of the failure. We should just traverse the type structure and do the various unwrapping calls ourselves, e.g dealiasing, unwrapping annotations, etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like the fold does the right thing here, the problem is that we didn't special-case for unapplySeq. I added a commit to do so, let's see if it breaks anything else.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, actually it might not be the fold. But it's nothing to do with unapplySeq. We just didn't carry over the && !isUnapplySeq that was also present for the product branch.

Moving it has the same affect (though it keeps it separate from the product match). But that unapplySeq change isn't right.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not? Shouldn't we also support generic tuples as a return type of unapplySeq, and shouldn't this be special-cased?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The point of unapplySeq is to define an extractor that can do runtime checks on the length of the sequence and operate on it (apply/drop/toSeq). But generic tuples, like all tuples and case class (i.e. all products), have a known length and we consume them as a products or product-like, not as a sequence, by directly accessing their components.

What use case were you thinking of?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

E.g.:

scala> object Foo:
     |   def unapplySeq(x: String): (Int, Seq[String]) = (x.length, x.toList.map(_.toString))

scala> "foo" match
     |   case Foo(1, c) => "One character " + c
     |   case Foo(x, xs*) => s"Many $x characters $xs"

We might want to use a generic tuple there.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough. But if you want to support it you should add tests that it actually works.

@anatoliykmetyuk anatoliykmetyuk merged commit 4105afb into scala:main Feb 14, 2022
@anatoliykmetyuk anatoliykmetyuk deleted the fix-11008 branch February 14, 2022 15:06
@bishabosha
Copy link
Member

Note: there is no documentation that product pattern for generic tuples > 22 elements does not need _N accessors: https://docs.scala-lang.org/scala3/reference/changed-features/pattern-matching.html#product-match

@Kordyjan Kordyjan added this to the 3.1.3 milestone Aug 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Whether support *: as a valid return type of unapply in extractors
4 participants