Make named tuples a standard feature #21680
Conversation
odersky
commented
Oct 1, 2024
odersky
commented
- Deprecate experimental language import
- Make named tuple features conditional on -source >= 3.6 instead
- Make the NamedTuple object non-experimental.
- Move NamedTuple it to src-bootstrapped since it relies on clause interleaving which is only standard in 3.6 as well.
- Drop the experimental.namedTuple import from tests
- Deprecate experimental language import - Make named tuple features conditional on -source >= 3.6 instead - Make the NamedTuple object non-experimental. - Move NamedTuple it to src-bootstrapped since it relies on clause interleaving which is only standard in 3.6 as well. - Drop the experimental.namedTuple import from tests
The previous syntax `before copy (name = ...)` is now interpreted as a binary operation with a named tuple on the RHS. The correct syntax is `before.copy(name = ...)`.
We sometimes face a problem that we inline a reference `x: T` which upon further inlining is adapted to an expected type `x`. It only seems to occur in complicated scenarios. I could not completely narrow it down. But in any case it's safe to drop the widening cast in order to avoid a type error here. We do that in a last-effort adaptation step that's only enabled in the Inliner: Faced with an expression `x: T` and a singleton expected type `y.type` where `x.type <: y.type`, rewrite to `x`.
|
#21413 was an Inliner problem. I managed to fix it in the last commit. |
|
Fixes #21413 |
Gedochao
added
the
needs-minor-release
|
@EugeneFlesselle I suggest to put any changes to Tuple/NamedTuple code in separate PRs. That way it's easier to coordinate. |
Ah I was about to finish my review. I'll submit the comments here anyway and we can see afterwards where to apply potential changes. |
|
Sorry, I was too hasty. Yes, please add the comments to this PR and I'll open another one that incorporates any changes. |
There was a problem hiding this comment.
As previously mentioned, there are a few cosmetic changes (pushed here) to the NamedTuple sources which I propose while we have the chance:
- Use the
NamedTupletype ops for the result types of the term ops - Drop
asInstanceOffrom the NamedTuple term ops where possible
Some similar minor things, which I think are fine, but could be considered before dropping @experimental:
- We could add a
NamedTuple.Uniontype alias for the union of the element types, we use it already twice within NamedTuples extension methods. - The type
Initcould be defined in terms ofTake, as we do forTailin terms ofDrop.
On the documentation side:
named-tuples.md#L206 mentions:
The operations on named tuples are defined in object scala.NamedTuple.
They are defined within the NamedTupleDecomposition object which we then export. This fine to ignore for the comment there. But more annoyingly however, it seems the exported methods do not show up in the linked documentation page.
NamedTuple.scala#L39-L44 has two commented out method definitions and a comment which I think went along methods which were since moved into NamedTupleDecomposition. Should we move or delete them?
And some final minor documentation notes, which again are probably fine, but to which I am bringing attention in case we wanted to add anything:
- There are a few NamedTuple members without any doc, namely
withNames,applyandunapply. - Perhaps we should mention, or reference to, the question of Conformance and Convertibility in the scaladoc of the
NamedTuple.NamedTupleopaque type definition.
This is a long comment but overall It's very cool to see named tuples become standard!
| @@ -1,5 +1,4 @@ | |||
| //> using options -source future | |||
There was a problem hiding this comment.
| //> using options -source future |
Should -source future still be necessary?
No problem! and sorry about the slow review |
|
Can we make a PR our of finalize-namedtuples-2 and do the changes proposed here on this one? |
I have opened #21710
All or any of them specifically? |
