Kotlin's Iterable and Sequence look exactly same. Why are two types required?

Question

Both of these interfaces define only one method

public operator fun iterator(): Iterator<T>

Documentation says Sequence is meant to be lazy. But isn't Iterable lazy too (unless backed by a Collection)?

Answer 1

The key difference lies in the semantics and the implementation of the stdlib extension functions for Iterable<T> and Sequence<T>.

• For Sequence<T>, the extension functions perform lazily where possible, similarly to Java Streams intermediate operations. For example, Sequence<T>.map { ... } returns another Sequence<R> and does not actually process the items until a terminal operation like toList or fold is called.

  Consider this code:

  val seq = sequenceOf(1, 2)
  val seqMapped: Sequence<Int> = seq.map { print("$it "); it * it } // intermediate
  print("before sum ")
  val sum = seqMapped.sum() // terminal
  

  It prints:

  before sum 1 2
  

  Sequence<T> is intended for lazy usage and efficient pipelining when you want to reduce the work done in terminal operations as much as possible, same to Java Streams. However, laziness introduces some overhead, which is undesirable for common simple transformations of smaller collections and makes them less performant.

  In general, there is no good way to determine when it is needed, so in Kotlin stdlib laziness is made explicit and extracted to the Sequence<T> interface to avoid using it on all the Iterables by default.

• For Iterable<T>, on contrary, the extension functions with intermediate operation semantics work eagerly, process the items right away and return another Iterable. For example, Iterable<T>.map { ... } returns a List<R> with the mapping results in it.

  The equivalent code for Iterable:

  val lst = listOf(1, 2)
  val lstMapped: List<Int> = lst.map { print("$it "); it * it }
  print("before sum ")
  val sum = lstMapped.sum()
  

  This prints out:

  1 2 before sum
  

  As said above, Iterable<T> is non-lazy by default, and this solution shows itself well: in most cases it has good locality of reference thus taking advantage of CPU cache, prediction, prefetching etc. so that even multiple copying of a collection still works good enough and performs better in simple cases with small collections.

  If you need more control over the evaluation pipeline, there is an explicit conversion to a lazy sequence with Iterable<T>.asSequence() function.