This commit is about not calling .length or .si...

This commit is about not calling .length or .size on Lists. Sometimes it
is unavoidable; not often. I created some methods for the compiler which
should probably be in the collections, which do things like test if two
sequences have the same length in a more efficient manner than calling
length on each.

Also, wouldn't it be wonderful to have some mechanism for finding these
issues in a more automated way. Like say an annotation:

  LinearSeqLike {
    @badjuju("Calling length on linear seqs is O(n)")
    def length: Int = whee
  }

Or since I imagine everyone thinks they're calling length with lists of
2 or 3, an optional runtime check which yelled if it sees you calling
length on a 600 element list, or worse:

  var i = 0
  while (i < myList.length) { // you don't want to see what this does
    f(myList(i)) ; i += 1;
  }

Uniformity of interface without uniformity of behavior leaves us with
traps. No review.

1 files changed, 1 insertions, 1 deletions

diff --git a/src/library/scala/collection/mutable/Builder.scala b/src/library/scala/collection/mutable/Builder.scala
index 701e39e36f..a2bac43ed2 100644
--- a/src/library/scala/collection/mutable/Builder.scala
+++ b/src/library/scala/collection/mutable/Builder.scala
@@ -54,7 +54,7 @@ trait Builder[-Elem, +To] extends Growable[Elem] {
   /** Gives a hint that one expects the `result` of this builder
    *  to have the same size as the given collection, plus some delta. This will
    *  provide a hint only if the collection is known to have a cheap
-   *  `size` method. Currently this is assumed ot be the case if and only if
+   *  `size` method. Currently this is assumed to be the case if and only if
    *  the collection is of type `IndexedSeqLike`.
    *  Some builder classes
    *  will optimize their representation based on the hint. However,