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.

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

Conversation

soronpo
Copy link
Contributor

@soronpo soronpo commented Nov 27, 2024

AnyNamedTuple should have a Tuple lower bound and a Product upper-bound

@soronpo soronpo requested a review from odersky November 27, 2024 05:15
@@ -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?

@odersky
Copy link
Contributor

odersky commented Nov 27, 2024

How important is the change? AnyNamedTuple was intended as a marker "only named tuples can go here". It was not supposed to have any functionality beyond that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants