A modern programming language that makes developers happier.

kotlinlang

Is `MutableCollection.addAll(Collection/Iterable/Sequence/Array`) faster if the input and/or output are certain types of collections?

there isn't an `Iterable.addAll` method; do you mean `MutableCollection.addAll`?

<https://github.com/JetBrains/kotlin/blob/master/libraries/stdlib/src/kotlin/collections/MutableCollections.kt#L114>
```fun &lt;T&gt; MutableCollection&lt;in T&gt;.addAll(elements: Iterable&lt;T&gt;): Boolean```
is an extension function which forwards to the
```interface MutableCollection&lt;E&gt; {
    fun addAll(elements: Collection&lt;E&gt;): Boolean
}```
member if `elements is Collection` else it adds the elements one-by-one. whether the member function `.addAll` does anything better depends on the receiver in question

`java.util.ArrayList`, which is what you'll get if you use `mutableListOf()` in Kotlin (in current implementation, not guaranteed by the API contract), does pre-allocate space so it can grow the backing array only once, but this has the same big-O amortized runtime

There's no special magic that some collections can be added in constant time or something? Maybe some compiler optimizations I can't see from the source?

the only way you could get O(1) is if the elements to be added are an immutable collection, which isn't a standard type that anything knows about

Meaning there are no immutable collections in Kotlin? Aren't there in Java?

there are some libraries such as <https://github.com/Kotlin/kotlinx.collections.immutable> but not in stdlib. no, although Java does now have builders for immutable collections (like Kotlin), it doesn't have types for them

e.g. `listOf()` and <https://docs.oracle.com/javase/9/docs/api/java/util/List.html#immutable|java.util.List.of()> are immutable, but you don't know it from the type

So `mutableListOf().addAll(listOf())` runs in linear time (no more efficient than `Iterable`), and adding an immutable list would theoretically be O(1), but there aren't any such types...?

adding an immutable list, *if* the receiver knew how to handle it and was structured in a particular way, could *potentially* be O(1), but in general can't be for an array-backed list

So it is all just linear? No point in converting an array to a list for addAll?

can't do better than linear if you have to copy O(n) elements

Can you do worse? Are there such worse implementations?

internally, ArrayList.addAll() does convert to an array first, so it can pre-allocate without worrying about inconsistencies between count() and iterator() of a mutable collection