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). We can do it anyway, but I think that adding this API would have been a "no-brainer" otherwise, and I'm not sure it's totally a "no-brainer" now. Naming: * Existing "at-index" methods tend to just end with "-At" (like `String.charAt()`). (I personally like ends-with-preposition naming, at least for single-arg methods like this.) * In fact, j.u.Vector names this very same method `removeElementAt`, but that seems unnecessarily wordy. The fact that j.u.Vector will end up with *three* methods that do the same thing might be sad if anyone really cared about j.u.Vector anymore. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31064#issuecomment-4423405317
