Imported From: https://issues.scala-lang.org/browse/SI-9175?orig=1
Reporter: @VladUreche
Affected Versions: 2.11.5

@VladUreche said:
Rex, how do you feel about adding a single element enqueue to mutable.Queue? I can do a PR against 2.12 if that's okay with you.

@Ichoran said:
I think it's really a shame that mutable.Queue doesn't have this, so if you can do it in a source-compatible way, that sounds good to me! However, something like .enqueue(xs: _*) would still need to work to maintain source compatibility. Adriaan is the one to ask if we want a performance vs. backwards compatibility tradeoff. (I think an implicit will do the trick, but it's a bit ugly to have in the API...maybe better to just wait until 2.13 and fix it properly.)

@ruippeixotog said:
@Ichoran, what about adding signatures like:

def enqueue[B >: A](elem: B): Unit
@deprecated(...) def enqueue[B >: A](elem: B, elem2: B, elems: B*): Unit
def enqueue[B >: A](iter: Iterable[B]): Unit

Unless I'm not missing some corner case, that would keep source compatibility and pave the path to an unified API for enqueuing in 2.13 - a single-element enqueue and an iterator enqueue.

@Ichoran said:
@ruippeixotog Well, there's the empty case, enqueue(), though I can't imagine why that would have been used. And if anyone extended mutable.Queue this definitely requires a good bit of work to retain compatibility. But it's not a bad idea. Maybe worth moving it up to 2.12 and seeing who complains? Maybe after we survey projects out there and see how often if ever we see mutable.Queue extended.

@ruippeixotog said:
On a second look, my suggestion breaks also code that calls enqueue as enqueue(elemSeq: _*). Maybe there is no way to do that without breaking source compatibility... how about defining += for single-element enqueues?

@scala/collections what's the status on this one — should this stay open?

fixed in 2.13