With respect to the naming, I think kotlin.collections.AbstractMutableList implements removeAt(int) with non-public visibility. If we then come along and say that there is a default public List.removeAt(int), AbstractMutableList would try (and fail) to assign a lower visibility, resulting in a compile-time error.
/Per ________________________________ From: [email protected] <[email protected]> Sent: Tuesday, May 12, 2026 6:23 PM To: Per-Ake Minborg <[email protected]> Cc: David Alayachew <[email protected]>; Archie L. Cobbs <[email protected]>; core-libs-dev <[email protected]> Subject: Re: [External] : Re: RFR: 8384062: Add a new method List::removeAtIndex to avoid overload confusion ________________________________ From: "Per-Ake Minborg" <[email protected]> To: "David Alayachew" <[email protected]>, "Remi Forax" <[email protected]> Cc: "Archie L. Cobbs" <[email protected]>, "core-libs-dev" <[email protected]> Sent: Tuesday, May 12, 2026 11:37:25 AM Subject: Re: [External] : Re: RFR: 8384062: Add a new method List::removeAtIndex to avoid overload confusion Changing language features is definitely out of scope for this issue. One thing to keep in mind is how methods can be manually resolved in case there are several interface methods with the same name from a plurality of implemented interfaces. Imagine the interfaces Foo and Bar both having a final bazz() method ... will work exactly the same way as with inheritance, when you have a final method which is overriden by another one class A { final void m() { ... } } class B extends A { final void m() { ... } } Best, Per Rémi ________________________________ From: David Alayachew <[email protected]> Sent: Tuesday, May 12, 2026 9:06 AM To: [email protected] <[email protected]> Cc: Archie L. Cobbs <[email protected]>; core-libs-dev <[email protected]> Subject: Re: [External] : Re: RFR: 8384062: Add a new method List::removeAtIndex to avoid overload confusion Rémi, I am talking about introducing a new language feature. As in, give interfaces the ability to define a method like so. @FunctionalInterface public BlahInterface { int blahImpl(); final int blahUsefulDerivedMethod() {/* do something with blahImpl() */} } Adding default feels like a needless signifier, but at this point, I am bikeshedding. On Tue, May 12, 2026 at 1:33 AM <[email protected]> wrote: > > > ------------------------------ > > *From: *"David Alayachew" <[email protected]> > *To: *"Remi Forax" <[email protected]> > *Cc: *"Archie L. Cobbs" <[email protected]>, "core-libs-dev" < > [email protected]> > *Sent: *Tuesday, May 12, 2026 3:21:17 AM > *Subject: *Re: [External] : Re: RFR: 8384062: Add a new method > List::removeAtIndex to avoid overload confusion > > Well, it would be better to just make it a final method in that case. No > point for the default. > > > We are trying to add a method to an existing interface hence the "default" > and > we are trying to avoid that method to be overridden hence the "final". > > regards, > Rémi > > > 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 >> > >
