On Tue, 12 May 2026 10:37:12 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). > > Per Minborg has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains three additional > commits since the last revision: > > - Merge branch 'master' into rfe-list-remove-at-index > - Add @apiNote > - Add List::removeAtIndex Regarding potential conflicts with `kotlin.collections.AbstractMutableList.removeAt()`... on the one hand we don't want to go out of our way to create gratuitous incompatibilities with Kotlin. On the other hand it's not clear to me whether this is actually an incompatibility. After all, that's a _Kotlin_ class and not a Java class. Kotlin might have completely different rules for overrides and conflicts. It takes an `Int` parameter which in a Kotlin class, which might be completely rewritten by the time it gets turned into a Java method descriptor. They might have ways of dealing with this sort of thing in their compiler. If we think that `removeAt` is definitely a better name, then we should do some investigation to see whether adding it would cause an actual problem. It might not be a problem at all. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31064#issuecomment-4445978196
