Move NonEmptyTuple members into Tuple
#21291
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bishabosha
reviewed
Jul 29, 2024
|
@bishabosha By the way, sorry I forgot this PR also had the tuple change for some reason, which I did not mean to assign to you. I'll split the PR into two, with an example of why the second commit is needed. |
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) | ^^^^^^^ ---------------------------------------------------------------------------- ```
Addressing scala#19175 The motivation for this has already been established, among other things: - the corresponding type level operations already use `Tuple` as upper bound; - the corresponding `NamedTuple` operations also do not make a distinction; - these operations are no more unsafe than other operations already available on `Tuple`, such as `drop` Note this should _not_ be a problem for binary compatibility, as both `Tuple` and `NonEmptyTuple` are erased to `Product`s (see `defn.specialErasure`).
EugeneFlesselle
force-pushed
the
tuples/nonempty-ops
branch
from
f8851a5
to
1cc3ea3
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The motivation for this has already been established, among other things:
Tupleas upper bound;NamedTupleoperations also do not make a distinction;Tuple, such asdrop.Note this should not be a problem for binary compatibility, as both
TupleandNonEmptyTupleare erased toProducts (seedefn.specialErasure).See #19175 (comment) for related changes.
Based on #21308