Named tuples 3 #20346
Named tuples 3 #20346
Commits on May 6, 2024
-
-
Improvements to Tuples: New methods
New methods: filter, indicesWhere, reverseOnto
-
-
-
-
-
-
-
-
-
-
-
Avoid widening into unreducible types when inferring types
This is a general improvement, independent of named tuples.
-
-
-
-
-
-
Better printing of NamedTuple type trees
Use the sugared representation, not the raw NamedTuple type tree.
-
-
-
-
Implement Fields as a Selectable type member
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.
-
-
Fix fields as a selectable type member
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.
-
Make NamedTuple.From work for named tuple arguments
NamedTyple.From should be the identity for named tuple arguments
-
-
inMode is useful, but its name is can easily be misinterpreted. Hopefully, withModeBits is better. Fixes rebase breakage where inMode was made private, but needs to be public since it is now used in Desugar.
-
Revert NamedArg term/type classification
Strip NamedArgs instead when making a term/type classification of tuples. The previous classification of NamedArgs as terms or types broke the completion test suite. It seems that completion relies on NamedArgs being neither types nor terms. And in a sense, that's correct. They are not.
-
-
-
It now work with just named tuples, no other extensions are needed.
-
-
Update documentation following review suggestions
Co-authored-by: Dale Wijnand <[email protected]>
-
-
-
Don't abbreviate tuple bindings if right-hand-side is named
We need to go through an explicit pattern match to drop the names.
-
Fix tuple selection in pattern matcher
The pattern matcher selects tuples up to 22 using _1, _2, ... But if the scrutinee is a named tuple this only works if it is cast to a regular tuple first.
-
-
-
-
-
-
-
Add an infix shorthand for
Append[X, Y]as is the case for `Concat`
-
-
-
Refine bounds of
type Filterpredicateto only require being defined on the element types. Similar to what we have for `type FlatMap`
-
-
Do
indexOfruntime operation based on term equalityand refine `type IndexOf` doc
-
-
-
Move
NonEmptyTuplemethods intoTupleThis 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.
-
-
-
-
Make named-tuples-strawman-2.scala a run test
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.
-
Revert the addition of
type FieldsinSelectable.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.
