Skip to content

make namedTupleCanEqual stable#26243

Open
bishabosha wants to merge 1 commit into
scala:mainfrom
dotty-staging:nt-canequal-drop-experimental
Open

make namedTupleCanEqual stable#26243
bishabosha wants to merge 1 commit into
scala:mainfrom
dotty-staging:nt-canequal-drop-experimental

Conversation

@bishabosha
Copy link
Copy Markdown
Member

Fixes #26242

How much have you relied on LLM-based tools in this contribution?

Not at all

How was the solution tested?

Covered by existing tests (this is a refactoring)

@bishabosha bishabosha added this to the 3.10.0 milestone Jun 5, 2026
@bishabosha bishabosha requested a review from a team as a code owner June 5, 2026 16:44
@WojciechMazur
Copy link
Copy Markdown
Contributor

Shouldn't this go through @preview stage first?

@bishabosha
Copy link
Copy Markdown
Member Author

bishabosha commented Jun 5, 2026

Shouldn't this go through @preview stage first?

Cc @Gedochao @tgodzik
@WojciechMazur someone should make this process crystal clear in a document because i am seeing conflicting messages e.g. #24675 (comment)

e.g. https://nightly.scala-lang.org/docs/contributing/procedures/contributing-to-stdlib.html says nothing about preview/experimental

Edit:
if i go back to 3.7.0 release notes it does seem to suggest that new API should be experimental and then preview @sjrd (https://scala-lang.org/news/3.7.0/#preview-features)

@odersky
Copy link
Copy Markdown
Contributor

odersky commented Jun 6, 2026

The preview scheme looks very heavy for library changes. Preview is primarily for tooling to catch up, but library changes should have no bearance on tooling. So I tend to think preview is not necessary for library changes.

@Gedochao
Copy link
Copy Markdown
Contributor

Gedochao commented Jun 8, 2026

The current default is for language features to spend one minor series in @preview after being promoted from @experimental, but before making them stable. There can, of course, be exceptions, but those should be run by Scala Core.

if i go back to 3.7.0 release notes it does seem to suggest that new API should be experimental and then preview @sjrd (https://scala-lang.org/news/3.7.0/#preview-features)

Yeah, I would also assume this should apply to new API, as well.

That said, I do agree this is heavy for library changes, so perhaps we can skip this step by default here.
I imagine there could be library changes we would like to put through @preview in the future, but likely not this one.

someone should make this process crystal clear in a document because i am seeing conflicting messages

Yeah, this is fair. Let's touch on this on this week's Scala Core.
We might need a dedicated doc.
cc @SethTisue this might be relevant to documenting features as per scala/scala-lang#1926

@Gedochao Gedochao requested a review from tgodzik June 8, 2026 07:38
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.

stablize CanEqual for named tuple

5 participants