More world-shaking deprecation work.

object, updating some @deprecated messages to give realistic
alternatives, properly resolving the semantic mismatch between List.--
and diff, its once-recommended but inequivalent alternative.

1 files changed, 4 insertions, 4 deletions

diff --git a/src/library/scala/collection/immutable/NumericRange.scala b/src/library/scala/collection/immutable/NumericRange.scala
index 9c70ba3ca6..67b097e65d 100644
--- a/src/library/scala/collection/immutable/NumericRange.scala
+++ b/src/library/scala/collection/immutable/NumericRange.scala
@@ -25,7 +25,7 @@ import generic._
  *    the Int-based scala.Range should be more performant.
  *  </p><pre>
  *     <b>val</b> r1 = new Range(0, 100, 1)
- *     <b>val</b> veryBig = Math.MAX_INT.toLong + 1
+ *     <b>val</b> veryBig = Int.MaxValue.toLong + 1
  *     <b>val</b> r2 = Range.Long(veryBig, veryBig + 100, 1)
  *     assert(r1 sameElements r2.map(_ - veryBig))
  *  </pre>
@@ -48,9 +48,9 @@ extends IndexedSeq[T]
   // todo? - we could lift the length restriction by implementing a range as a sequence of
   // subranges and limiting the subranges to MAX_INT.  There's no other way around it because
   // the generics we inherit assume integer-based indexing (as well they should.)
-  // The second condition is making sure type T can meaningfully be compared to Math.MAX_INT.
-  if (genericLength > fromInt(Math.MAX_INT) && (Math.MAX_INT == toInt(fromInt(Math.MAX_INT))))
-    fail("Implementation restricts ranges to Math.MAX_INT elements.")
+  // The second condition is making sure type T can meaningfully be compared to Int.MaxValue.
+  if (genericLength > fromInt(Int.MaxValue) && (Int.MaxValue == toInt(fromInt(Int.MaxValue))))
+    fail("Implementation restricts ranges to Int.MaxValue elements.")
 
   // inclusive/exclusiveness captured this way because we do not have any
   // concept of a "unit", we can't just add an epsilon to an exclusive