Imported From: https://issues.scala-lang.org/browse/SI-9068?orig=1
Reporter: @sschaef
Affected Versions: 2.11.4

@Ichoran said:
I would like to get a sense of the usage in the wild before we decide on deprecation. I would like to, but the cost of leaving it in is not enormous, so if it would be painful I'd want to reconsider. (That said, I don't know why one would want to use this class. Deprecation can be viewed as instruction, I guess.)

Chris Martin (chris-martin) said (edited on Jan 4, 2015 10:12:56 AM UTC):
Is this about discouraging impurity, or are you saying that you don't think {{mutable.Stack}} adds any value over a var of type List?

If the deprecation instructions would be to rewrite

val stack: collection.mutable.Stack[A] = ???

val x = stack.pop()

stack.push(y)

as

var stack: List[A] = ???

val x = stack.head
stack = stack.tail

stack +:= y

then I think the result is clearly worse.

@Ichoran said:
[~chris-martin] The specific example you give adds value, but not very much value. And you lose value at the same time. Take for instance

  var stack: List[A] = ???
  stack = prefix ::: stack

You'd think that

  var stack: mutable.Stack[A] = ???
  stack = prefix ++: stack

might work, but you'd be wrong because ++: isn't overridden. (Even +: isn't overridden.) You have to use pushAll instead. And dropWhile? Nope, it defers back to TraversableLike, which makes a new builder and reallocates the tail all over again.

So you are left with a convenience class that looks like it nicely encapsulates mutability, but in fact is full of unexpected performance gotchas because it turns out that to override everything relevant is actually really tedious and difficult to keep straight, especially as the library evolves.

It's better to just be honest about the situation and deprecate it than to try to fix all the problems now and then maintain the fixes every time the library changes.

Chris Martin (chris-martin) said:
Would it be feasible to deprecate only the inheritance, and let a simpler Stack class survive on its own?

I'd find it rather disheartening if Scala lost its stack as a result of getting lost down rabbit holes like ++: which are so distant from the purpose of a stack.

@sschaef said:
Java has the Deque interface, you can use that one if you really want a push/pop API.

@szeiger said:
As discussed in the Scala team meeting, we should deprecate this in 2.12.

@szeiger said:
PR: scala/scala#5260