Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add tighter bounds on AnyNamedTuple #22037

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Add tighter bounds on AnyNamedTuple #22037

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion library/src/scala/NamedTuple.scala
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ object NamedTuple:
opaque type NamedTuple[N <: Tuple, +V <: Tuple] >: V <: AnyNamedTuple = V

/** A type which is a supertype of all named tuples */
opaque type AnyNamedTuple = Any
opaque type AnyNamedTuple >: Tuple <: Product = Product
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We cannot change the right hand side anymore. It breaks binary and TASTy compatibility.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we assume 3.6.0 and 3.6.1 do no exist, then we're still in the RC period where modifications are allowed. We're currently at 3.6.2-RC2, and it's probably the last moment before signatures would be written in stone forever.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regardless, if we are making such a change at this point, it means named tuples are not ready for prime time.

So either we back out and make them experimental again, or we don't touch them except for bug fixes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which makes me realize that we need another strategy to roll out new features. Hardly anybody uses them when they are experimental. And when we stabilize small nits like this one inevitably pop up. Which means we have only three choices:

  • we accept that it's imperfect and freeze anyway
  • we roll back, which means that we cannot get anything substantial into the language anymore, ever
  • we accept some breakage to fix nits such as this one, for a limited period.

I am not sure what to do here. Java has previews, would that help?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should discuss it later today, but some thoughts on the topic:

  • people are testing it in an experimental RC Scala version (though named as 3.6.1 due to known reasons), so I wouldn't say that hardly anyone tests experimental stuff
  • the period for experimenting with it was rather short though (less than 3 months) and making it stable felt rushed just before 3.6.0 cutoff. I think a lot of people including us were surprised by this.
  • there is a lot of discussion about it and uncertainty, so it would make sense to make it experimental again as a nod to the community. It's always better to be careful than not and better to not to risk antagonizing the community if not needed.

I think we should:

  • mark it back as experimental
  • make as much publicity about the feature as possible to encourage people to try it out. We usually promote released features, we should also promote heavily anything that experimental that we merge.
  • make sure that the details are discussed and we announce making it stable in the next release (another section in release notes like 'becoming stable'). If no one has anything serious to add we go ahead.

I fully understand your feelings here, things might be slow moving, but is there really a need to rush it? I think the best result we can get is having people actively discuss any new features, which indeed happened with named tuples and we should make it happen every time new experimental is dropped.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be mentioned here that the SIP committee can approve a feature to be accepted, and it's the compiler's team decision when to actually merge it as non-experimental.


def apply[N <: Tuple, V <: Tuple](x: V): NamedTuple[N, V] = x

Expand Down
Loading