----- 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
