Named tuples 3 #20346
Named tuples 3 #20346
Conversation
New methods: filter, indicesWhere, reverseOnto
Also, add deep matches to tests
This is a general improvement, independent of named tuples.
Use the sugared representation, not the raw NamedTuple type tree.
Subclasses of Selectable can instantiate Fields to a named tuple type that provides possible selection names and their types on instances of the type. See: https://contributors.scala-lang.org/t/expanding-changing-selectable-based-on-upcoming-named-tuples-feature/6395/5
I usually try to avoid explicit returns, but here they do make the code easier to read.
The selectDynamic call could already have influenced type variables in the expected type before we wrap it in a cast. Need to pass in the right expected type to the typedDynamicSelect.
NamedTyple.From should be the identity for named tuple arguments
as is the case for `Concat`
to only require being defined on the element types. Similar to what we have for `type FlatMap`
and refine `type IndexOf` doc
This is for the same reason as we changed `type Head[X <: NonEmptyTuple] = ...` to `type Head[X <: Tuple] = ...` Also, this is no more unsafe than the other operations already defined for all tuples. `drop(1)` for example was always defined, even though `tail` wasn't.
The tuple term level definitions were not being tested before
For the two operations that we really need for NamedTuple, we define them as "internal" helpers inside NamedTuple. We remove or amend tests that relied on the changes to Tuple. No tests about NamedTuple's are affected.
If we add it as is now, we will *not* be able to add the bound in a future release. It is best to leave it completely undefined. The typer is happy to ignore the case where it does not exist at all.
|
Relevant failure: If added new experimental definitions to the library, add them to the list in tests/run-tasty-inspector/stdlibExperimentalDefinitions.scala Test only: sbt "scala3-bootstrapped/testCompilation tests/run-tasty-inspector/stdlibExperimentalDefinitions.scala" |
|
I don't think we should backtrack on FutureTupleOps again. This is just causes friction and statis. Any improvement to Tuple is welcome, and should not be held up. If it has been thoroughly reviewed it should not be experimental. I am going agead with the minimum changes to Tuple that make NamedTuple work and these will not be experimental. It's all very good to hedge our bets, but we have seen in the past that this means progress will be delayed indefinitely. Otherwise, why would Tuple.scala still be in the bad state it is? |
Yes, OK. Fine by me as long as it's only minimal additions. |
|
OK, I incorporated all changes into named-tuples-2. We should do a separate effort to clean up Tuple in the next cycle. @EugeneFlesselle did a good job in dotty-staging#41 to split into reviewable commits. Maybe we can build on that? |
OK, closing this one as superseded by #19174.
Yes, absolutely. |
No description provided.