Well, it would be better to just make it a final method in that case. No point for the default.
On Mon, May 11, 2026 at 6:51 PM Remi Forax <[email protected]> wrote: > ----- Original Message ----- > > From: "Archie L. Cobbs" <[email protected]> > > To: "core-libs-dev" <[email protected]> > > Sent: Monday, May 11, 2026 8:04:08 PM > > Subject: Re: RFR: 8384062: Add a new method List::removeAtIndex to avoid > overload confusion > > > On Thu, 7 May 2026 06:45:36 GMT, Per Minborg <[email protected]> > wrote: > > > >> This PR proposes to add a new `default` method `List::removeAtIndex`. > >> > >> There are two overloads of the method `List::remove`, and if the list > is of type > >> `List<Integer>`, the overload resolution could pick a surprising > variant. > >> > >> Hence, it is better to add a separate method that removes an element > based on > >> its index. > >> > >> It is proposed that the `E remove(int index)` method is _not_ > `@Deprecated`. > >> Instead, we add verbiage to promote the new method over the old one. > >> > >> --------- > >> - [X] I confirm that I make this contribution in accordance with the > [OpenJDK > >> Interim AI Policy](https://openjdk.org/legal/ai). > > > > I sympathize with this change: `remove` is a textbook example of "bad > > overloading". > > > > I also definitely sympathize with Remi's concern: we have two > > identically-behaving methods where one is the most correct one to invoke > while > > the other is the most correct one to override. That's not ideal! We'd be > happy > > if API-clients pretty much *forgot* `remove(int)` existed, but when they > go to > > extend `AbstractList` we want them to suddenly remember. > > > > I don't think there's a fix for this (barring extremely weird ideas). > > Do you classify "default final" methods to say: you can use it but you can > not override it, as a weird idea ? > > regards, > Rémi > > > > > ------------- > > > > PR Comment: > https://git.openjdk.org/jdk/pull/31064#issuecomment-4423405317 >
