CODEWITHSUNDEEP
scalaforeachscala-collectionsside-effects
GreyCat
GreyCat

Reputation: 17132

Scala: "map" vs "foreach" - is there any reason to use "foreach" in practice?

In Scala collections, if one wants to iterate over a collection (without returning results, i.e. doing a side effect on every element of collection), it can be done either with

final def foreach(f: (A) ⇒ Unit): Unit

or

final def map[B](f: (A) ⇒ B): SomeCollectionClass[B]

With the exception of possible lazy mapping(*), from an end-user perspective, I see zero differences in these invocations:

myCollection.foreach { element =>
  doStuffWithElement(element);
}

myCollection.map { element =>
  doStuffWithElement(element);
}

given that I can just ignore what map outputs. I can't think of any specific reason why two different methods should exist & be used, when map seems to include all the functionality of foreach, and, in fact, I would be pretty much impressed if an intelligent compiler & VM won't optimize out that collection object creation given that it's not assigned to anything, or read, or used anywhere.

So, the question is - am I right - and there are no reasons to call foreach anywhere in one's code?

Notes:

(*) The lazy mapping concept, as throughly illustrated in this question, might change things a bit and justify usage of foreach, but as far as I can see, one specifically needs to stumble upon a LazyMap, normal

(**) If one's not using a collection, but writing one, then one would quickly stumble upon the fact that for comprehension syntax syntax is in fact a syntax sugar that generates "foreach" call, i.e. these two lines generate fully equivalent code:

for (element <- myCollection) { doStuffWithElement(element); }
myCollection.foreach { element => doStuffWithElement(element); }

So if one cares about other people using that collection class with for syntax, one might still want to implement foreach method.

Upvotes: 18

Views: 13594

Answers (3)

samthebest
samthebest

Reputation: 31553

I can think of a couple motivations:

  1. When the foreach is the last line of a method that is of type Unit your compiler will not give an warning but will with map (and you need -Ywarn-value-discard on). Sometimes you get warning: a pure expression does nothing in statement position; you may be omitting necessary parentheses using map but wouldn't with foreach.
  2. General readability - a reader can know that your mutating some state without returning something at a glance, but greater cognitive resources would be required to understand the same operation if map was used
  3. Further to 1. you also can have type checking when passing named functions around, then into map and foreach
  4. Using foreach won't build a new list, so will be more efficient (thanks @Vishnu)

Upvotes: 17

som-snytt
som-snytt

Reputation: 39587

I'd be impressed if the builder machinery could be optimized away.

scala> :pa
// Entering paste mode (ctrl-D to finish)

implicit val cbf = new collection.generic.CanBuildFrom[List[Int],Int,List[Int]] {
def apply() = new collection.mutable.Builder[Int, List[Int]] {
val b = new collection.mutable.ListBuffer[Int]
override def +=(i: Int) = { println(s"Adding $i") ; b +=(i) ; this }
override def clear() = () ; override def result() = b.result() }
def apply(from: List[Int]) = apply() }

// Exiting paste mode, now interpreting.

cbf: scala.collection.generic.CanBuildFrom[List[Int],Int,List[Int]] = $anon$2@e3cee7b

scala> List(1,2,3) map (_ + 1)
Adding 2
Adding 3
Adding 4
res1: List[Int] = List(2, 3, 4)

scala> List(1,2,3) foreach (_ + 1)

Upvotes: 4

Chris Martin
Chris Martin

Reputation: 30756

scala> (1 to 5).iterator map println
res0: Iterator[Unit] = non-empty iterator

scala> (1 to 5).iterator foreach println
1
2
3
4
5

Upvotes: 8

Related Questions