A modern programming language that makes developers happier.

kotlinlang

Just noticed - there's no `List&lt;T&gt;.take(n: Int): List&lt;T&gt;` only `Iterable&lt;T&gt;.take(n: Int): List&lt;T&gt;` 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&lt;T&gt;.take(n: Int): List&lt;T&gt; = 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&lt;T&gt; : List&lt;T&gt;` 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

kotlinx.immutable takes the approach of providing its own extension functions, which will be used if imported. although it only has `plus` and `minus` currently, no reason `take` etc. couldn't use the same pattern. does have the downside of being difficult to tell what is happening locally though

“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 :face_with_rolling_eyes:

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

on a similar note, C++11 also ended up forbidding implementations from sharing backing buffers between strings, justified by <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2668.htm> (although the situation there was a bit different due to mutable strings)