Just noticed - there's no

List<T>.take(n: Int): List<T>

only

Iterable<T>.take(n: Int): List<T>

which constructs a new ArrayList and copies elements in. Wouldn't this be more efficient on a List, as it could just return a view?

fun List<T>.take(n: Int): List<T> = subList(0, n)

(And of course the same for

drop

)

that would make it susceptible to changes in the backing list which i suspect would surprise people

I wish Kotlin had made the default implementation of Lists immutable

wouldn't help unless you forbid calling that function on mutable lists, which requires a different type hierarchy

Yes, I was imagining an

ImmutableList<T> : List<T>

interface as a parallel to

MutableList

It's a times like these I wonder if having

.take

be an extension function was a good idea. If it were a regular interface method with default implementation, immutable list implementations could have overriden it to provide a subList-based implementation when it's safe

kotlin collections intentionally reuse java collections, so adding new member functions is not possible

“which will be used if imported” ← except if you use polymorphism, which you likely do

An additional consideration is that if

take

was implemented as

subList

(given that the

take

contract is respected, for example, by doing so only for immutable lists), it could lead to retaining more objects from garbage collection than necessary. Suppose you have a large list, but only temporary, and you want to take and store for a long period a list of only several first elements from it. If you use

take

for that, and

take

is implemented as a view, it would retain the entire large list in memory when only several elements of it are needed.

And, indeed, I've seen multiple people complaining here that

String.substring

retains the original string 🙄

They changed that in Java 7

AFAIK

substring

no longer does that.

Really? Damn.

yes, that was https://bugs.openjdk.org/browse/JDK-6924259