Why does Scala maintain the type of collection not return Iterable (as in .Net)?

Question

In Scala, you can do

val l = List(1, 2, 3)
l.filter(_ > 2)               // returns a List[Int]
val s = Set("hello", "world")
s.map(_.length)               // returns a Set[Int]

The question is: why is this useful?

Scala collections are probably the only existing collection framework that does this. Scala community seems to agree that this functionality is needed. Yet, noone seems to miss this functionality in the other languages. Example C# (modified naming to match Scala's):

var l = new List<int> { 1, 2, 3 }
l.filter(i => i > 2)          // always returns Iterable[Int]
l.filter(i => i > 2).toList   // if I want a List, no problem
l.filter(i => i > 2).toSet    // or I want a Set

In .NET, I always get back an Iterable and it is up to me what I want to do with it. (This also makes .NET collections very simple) .

The Scala example with Set forces me to make a Set of lengths out of a Set of string. But what if I just want to iterate over the lengths, or construct a List of lengths, or keep the Iterable to filter it later. Constructing a Set right away seems pointless. (EDIT: collection.view provides the simpler .NET functionality, nice)

I am sure you will show me examples where the .NET approach is absolutely wrong or kills performance, but I just can't see any (using .NET for years).

Answer 1

Not a full answer to your question, but Scala never forces you to use one collection type over another. You're free to write code like this:

import collection._
import immutable._

val s = Set("hello", "world")
val l: Vector[Int] = s.map(_.length)(breakOut)

Read more about breakOut in Daniel Sobral's detailed answer to another question.

If you want your map or filter to be evaluated lazily, use this:

s.view.map(_.length)

This whole behavior makes it easy to integrate your new collection classes and inherit all the powerful capabilities of the standard collection with no code duplication, all of this ensuring that YourSpecialCollection#filter returns an instance of YourSpecialCollection; that YourSpecialCollection#map returns an instance of YourSpecialCollection if it supports the type being mapped to, or a built-in fallback collection if it doesn't (like what happens of you call map on a BitSet). Surely, a C# iterator has no .toMySpecialCollection method.

See also: “Integrating new sets and maps” in The Architecture of Scala Collections.

Answer 2

Scala follows the "uniform return type principle" assuring that you always end up with the appropriate return type, instead of loosing that information like in C#.

The reason C# does it this was is that their type system is not good enough to provide these assurances without overriding the whole implementation of every method in every single subclass. Scala solves this with the usage of Higher Kinded Types.

Why Scala has the only collection framework doing this? Because it is harder than most people think it is, especially when things like Strings and Arrays which are no "real" collections should be integrated as well:

// This stays a String:
scala> "Foobar".map(identity)
res27: String = Foobar
// But this falls back to the "nearest" appropriate type:
scala> "Foobar".map(_.toInt)
res29: scala.collection.immutable.IndexedSeq[Int] = Vector(70, 111, 111, 98, 97, 114)