Currently "containers" (in general) in Kotlin are just library classes. There's nothing "special" about them. On one hand, it gives additional flexibility - like, you can potentially have containers with side effects in container operations. On the other hand, compiler (and JIT) can't perform optimizations that, for example, skip some operations (like creating an intermediate container), or change evaluation order. Since most collection operations work with abstract collections, you can't do such optimizations "in general". We have some ongoing discussion about collection literals & loop fusion (you'd usually call that "deforestation" in functional context). In 1.4 scope, maybe.

I see, thanks for the explenation!