I'm all for it, but when I started on my (long) list of dealing with deprecated stuff and cleanups, all of them were vetoed because of the special status for 2.12. Can someone clarify whether that position has changed recently?

@soc I was asked by @adriaanm to do the "finalization" of collection base classes. I don't know how well the tuple changes will be received, so I split it up into separate commits.

I'm all for it, but when I started on my (long) list of dealing with deprecated stuff and cleanups, all of them were vetoed because of the special status for 2.12. Can someone clarify whether that position has changed recently?

it depends on the specifics. if you can share that list, I could look it over.

I don't know how well the tuple changes will be received

Not well, not well at all. Ironically enough we're depending on this functionality in a library that you wrote.

Was under the impression (from discussion several months ago) that it was too late to remove tuple inheritance for 2.12 and planned accordingly.

@godenji You forked an old version of Slick or ScalaQuery and made it work on 2.12? Slick hasn't required Tuple subclasses anymore for a long time.

@szeiger forked ScalaQuery, have built against 2.9, 2.10, and 2.11, and intend to do the same for 2.12. This change will break it. In the scheme of things this is a total adhoc last minute change (really, 2.12 RC is 3 months away).

Thanks for the feedback, @godenji! This is exactly why we have PRs like this. Our intention is certainly not to gratuitously break code in 2.12, but to set the scene for 2.13 to simplify collections and other parts of the library.

We won't go ahead with the changes that negatively affect the community, and certainly not if they hamper cross-building between 2.11/2.12. For the record, I don't think the change is ad-hoc or last-minute (since it was announced using deprecation in 2.11).

on making tuples final, I think should this probably wait for 2.13, actually? @deprecatedInheritance is already in place, so the stage is already set for 2.13, I think, and the 2.11/2.12 cross building argument takes precedence — unless the change is truly especially desirable. @lrytz, are there implications for the new optimizer? if making tuples final enabled some juicy speedups, maybe that would tip the balance the other way.

reassigning to M5 since M4 is getting very close and to give time for discussion.

@adriaanm sure, I understand the rationale for the change. I assume that removing tuple inheritance in 2.13 won't hinder existing 2.12 optimizations (i.e. 2.13 collections overhaul is where actual performance improvement from the removal will be realized).

@SethTisue it seems there are already some quite juicy speedups on the horizon 🎉

What about the collection classes? deprecatedInheritance was added to them in 2.11, same as the tuples, so they're all in the same boat when in comes to cross-compiling between 2.11 and 2.12.

are there implications for the new optimizer?

no; we optimize allocations of tuples, in which case we know that the specific tuple type (not a subtype) is instantiated.

What about the collection classes? [...] they're all in the same boat

yes, good point.

but I haven't heard — well, maybe I have, but this PR doesn't contain or link to it — the case for the prosecution — why is it good to do this in 2.12 and not just wait for 2.13?

I'm aware of why we want final here (https://issues.scala-lang.org/browse/SI-8214, https://groups.google.com/d/msg/scala-internals/R4fTU_5XVZs/-eGpt3fkmJ8J), I'm just asking about the timing.

Was under the impression (from discussion several months ago) that it was too late to remove tuple inheritance for 2.12 and planned accordingly

@godenji link?

link?

@SethTisue sure, right here

I think that would violate the 2.11/2.12 source compatibility policy. 2.12 doesn’t remove deprecated things from 2.11.

and

library changes like acting on deprecatedInheritance are scheduled for 2.13

Removed tuple changes.

Updated the failing test to extend mutable collections instead.

LGTM

FTR, I finally got time to resolve TupleN issue in ScalaQuery. Here's the Gitter reference. @retronym says in 2.12 M5 can revisit issue for making TupleN final.

Apologies for the blocker, hopefully not too late...