improvement-proposals
improvement-proposals copied to clipboard
scala
SIP-58 - Named Tuples
There are a lot of good suggestions to add more sections to the proposal, but I am out of time to do this. Maybe someone else wants to help? There's an implementation to play with to experiment and find out more.
would name tuples be incubated as experimenta feature for a period of time? guess there could be more feedback after people start to play with them
would really like to see how they play with type level programming
would name tuples be incubated as experimenta feature for a period of time?
Every new Scala feature is first approved for experimentation, before it is approved to be shipped. The time between those milestones is at least a month, and should be longer for controversial features or features that interact with significant parts of the language. What is approved as experimental is only testable under a nightly or snapshot versions of the compiler and usually involves enabling some flag or importing language.experimental.
@kyouko-taiga I changed the stage label to stage:implementation - as that is required by our state transition diagram (and the script that generates the sips website):
A few points raised at the last SIP meeting:
- There is currently a soundness bug with NamedTuple.From: https://github.com/scala/scala3/issues/20517
- we believe the fix will require refining the specification of NamedTuple.From to reuse a check for reduction from the match type logic: https://github.com/scala/scala3/blob/0a3497bf7f0ac032f98d36cf1713e8926b5d176c/compiler/src/dotty/tools/dotc/core/TypeComparer.scala#L3397-L3410. This should be reflected in the spec, which should link to the corresponding section of https://docs.scala-lang.org/sips/match-types-spec.html (but it seems to me that right now the match type spec does not precisely defined "concrete" either? Note also that the current match type concreteness check implementation is too lax in some cases: https://github.com/scala/scala3/issues/20518)
- @sjrd suggested that NamedTuple should be implemented as a class (with a custom erasure) rather than an abstract type to avoid unintuitive restrictions related to match types (e.g., https://github.com/scala/scala3/issues/20453)
- I've also recently realized that pattern matching on a quoted type is broken for parameterized abstract types (you get a MatchError: https://github.com/scala/scala3/issues/16782), this means that meta-programming with NamedTuple is significantly harder than with regular Tuple currently.
Disallow some opaque type aliases in match type patterns #20913 should address the problem with failing match type reductions. It serves as a safety net ensuring that match type reduction on opaque aliases will not fail later.
I changed the stage label to stage:implementation - as that is required by our state transition diagram (and the script that generates the sips website)
Does that mean that the design has been accepted by the SIP Committee? If that’s the case, it would be good to merge the PR so that the proposal gets its own page like e.g. https://docs.scala-lang.org/sips/polymorphic-eta-expansion.html.
I changed the stage label to stage:implementation - as that is required by our state transition diagram (and the script that generates the sips website)
Does that mean that the design has been accepted by the SIP Committee? If that’s the case, it would be good to merge the PR so that the proposal gets its own page like e.g. https://docs.scala-lang.org/sips/polymorphic-eta-expansion.html.
Only as experimental. Not final yet.
It would be good if the recommendations of each assignee could be stated here prior to the vote.
