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

move NamedTuple methods to separate scope. re-export #20504

Merged
merged 3 commits into from
Jun 14, 2024

Conversation

bishabosha
Copy link
Member

By moving the methods to NamedTupleDecomposition, there is no issue with trying to reconcile types at inlining

fixes #20427

Copy link
Member

@smarter smarter left a comment

Choose a reason for hiding this comment

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

This looks like it'll make named tuples more robust.

@smarter
Copy link
Member

smarter commented Jun 12, 2024

I'd love to see this merged since I ran into this in practice.

@smarter smarter merged commit 0e63753 into scala:main Jun 14, 2024
24 checks passed
@smarter smarter deleted the named-tuples-methods branch June 14, 2024 12:46
@Kordyjan Kordyjan added this to the 3.5.1 milestone Jul 3, 2024
EugeneFlesselle added a commit to dotty-staging/dotty that referenced this pull request Jul 9, 2024
EugeneFlesselle added a commit that referenced this pull request Jul 9, 2024
EugeneFlesselle added a commit to dotty-staging/dotty that referenced this pull request Jul 29, 2024
avoid problems encountered after inlining from scopes defining opaque types;
as was already done for the other NamedTuple operations in scala#20504.
EugeneFlesselle added a commit to dotty-staging/dotty that referenced this pull request Jul 31, 2024
This is in particular necessary for scala#21291,
to avoid problems encountered after inlining from scopes defining opaque types
(such as in the example below),
as was already done for the other NamedTuple operations in scala#20504.

```scala
-- Error: tests/pos/named-tuple-combinators.scala:46:17 ------------------------
46 |    val res1 = x.head
   |               ^^^^^^
   |(Int, String) does not conform to bound >:
   |  (x$proxy55 : (x : Test.NT) &
   |    $proxy19.NamedTuple[
   |      Tuple.Concat[
   |        NamedTupleDecomposition.Names[
   |          $proxy19.NamedTuple[Tuple1[("hi" : String)], Tuple1[Int]]],
   |        NamedTupleDecomposition.Names[
   |          $proxy19.NamedTuple[Tuple1[("bla" : String)], Tuple1[String]]]
   |      ],
   |      Tuple.Concat[
   |        NamedTupleDecomposition.DropNames[
   |          $proxy19.NamedTuple[Tuple1[("hi" : String)], Tuple1[Int]]],
   |        NamedTupleDecomposition.DropNames[
   |          $proxy19.NamedTuple[Tuple1[("bla" : String)], Tuple1[String]]]
   |      ]
   |    ]
   |  )
   | <: Tuple
   |----------------------------------------------------------------------------
   |Inline stack trace
   |- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   |This location contains code that was inlined from NamedTuple.scala:47
47 |    inline def head: Tuple.Elem[V, 0] = x.apply(0)
   |                                        ^^^^^^^
    ----------------------------------------------------------------------------
```
bishabosha added a commit that referenced this pull request Jul 31, 2024
This is in particular necessary for #21291,
to avoid problems encountered after inlining from scopes defining opaque
types (such as in the example below),
as was already done for the other NamedTuple operations in #20504.
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.

NamedTuple selection on the result of NamedTuple.Concat doesn't work
5 participants