Why does Option not extend the Iterable trait directly?

Question

Option is implicitly convertible to an Iterable - but why does it not just just implement Iterable directly:

def iterator = new Iterator[A] {
  var end = !isDefined
  def next() = {
    val n = if (end) throw new NoSuchElementException() else get
    end = true
    n
  }

  def hasNext = !end
}

EDIT: In fact it's even weider than that because in 2.8 Option does declare an iterator method:

def iterator: Iterator[A] = 
  if (isEmpty) Iterator.empty else Iterator.single(this.get)

You could always change the source code and see what breaks. :-) — Daniel C. Sobral, Apr 09 '10 at 12:03
Well, `isEmpty` would need an `override` modifier for starters! I just wondered whether it was a conceptual thing — oxbow_lakes, Apr 09 '10 at 12:19
I guess that's because Option is a monad and not a collection. To me it makes sense that collections are iterable, but a monad is not a collection right away. Btw: I don't know about Scala 2.7, but in 2.8 Option.iterator is implemented using Iterator.empty and Iterator.single. — Michel Krämer, Apr 09 '10 at 16:02
If it's not a collection, why does it have an `iterator` method in 2.8? I also think that the FP mafia will be down on you for implying that somethings is *either* a collection or a monad. Quite clearly `List` and `Option` are both monads because they have a `pure` and a `bind` method, conceptually — oxbow_lakes, Apr 09 '10 at 16:14
I did not say that something is either a collection or a monad. Of course, collections are monads the way they are implemented in Scala, but not every monad is also a collection. — Michel Krämer, Apr 09 '10 at 16:31
@Michel - apologies; I thought the "Option is a Monad, not a collection" statement implied you meant that anything which was a monad could not be a collection. — oxbow_lakes, Apr 09 '10 at 16:38
Dual question: Why does anything implement Iterable directly? Why not just do it the way Option does it? — Apocalisp, Apr 09 '10 at 19:44

Mitch Blevins · Accepted Answer · 2010-04-11T07:03:10.283

9

I'm thinking that there were too many non-nonsensical methods that would be required. For example, what would you expect the return value to be for:

Some(1) ++ Some(2)

This currently compiles and evaluates to List(1,2) via implicits in 2.8, but seems odd.

Maybe that is why the doc comments in 2.7 say:

Only potentially unbounded collections should directly sub-class Iterable

Edit: As shown in @MattR's comment below, me leaving out the doc-comment recommendation to sub-type Collection is potentially misleading. And considering it morphs this question into "Why does Option not extend the Collection trait?"

edited Apr 11 '10 at 07:03

answered Apr 09 '10 at 20:26

Mitch Blevins

13,186
3
44
32

2

The documentation says, "If a collection has a known size, it should also sub-type Collection. Only potentially unbounded collections should directly sub-class Iterable". – Matt R Apr 10 '10 at 08:52
@oxbow: I'm not sure it should! The question is then only slightly different: why should Option not subtype Collection, which is a "Variant of Iterable used to describe collections with a finite number of elements"? – Matt R Apr 10 '10 at 13:13

Why does Option not extend the Iterable trait directly?

1 Answers1