LGTM. Can we changehashCode in a minor release?

LGTM. Can we change hashCode in a minor release?

Yes, as documented since 2020, as per#9051 andscala/bug#11646 . Admittedly that issue and PR didn't attract much attention/discussion. But they also haven't attracted any pushback, either at the time or in the years since. cc @scala/collections@Ichoran

Let's release-note it regardless (especially since the 2.13.16 release notes won't be that long).

In a Scala 3 context, it's a bit less clear-cut. Normally Scala 3 takes our standard libraryminor version bumps in their Scala LTSpatch version bumps. Does that change the answer here? I would argue it doesn't, because

• it's documented as being fair game (though I admit there is some ambiguity around the "patch version" wording; we normally say that Scala 2 versions are "epoch.major.minor" not "major.minor.patch", so the doc can be read as referring to Scala 2 minor versions even if it literally says "patch")
• it's a bugfix or refinement, not a feature addition or design change. we are bringing the implementation in line with an intention that has not changed
• people realllllllly shouldn't be relying on this stuff not changing — so if it changes once in a while (for a good reason), it's a good reminder of that

I don't doubt that some codebases will see some test failures because they were (perhaps inadvertently) relying on hash order, but IMO our stance should be that those tests were overly sensitive to begin with and it's normal to ask users to either 1) make them less sensitive, or 2) leave them sensitive for convenience but with the awareness that as a consequence they may need adjusting at Scala version bump time.

How will this cope withSeq(17) compared to17 to 17?

How will this cope withSeq(17) compared to17 to 17?

In the changed code paths, we already know thesize >= 2, soSeq(17) is not affected by this PR.

@Friendseeker could you squash the changes in a single commit?

@Friendseeker could you squash the changes in a single commit?

Done!