SLC: Merge mutable.ArrayDeque into mutable.Buffer on the JVM

[bishabosha]

@Sporarum

Particularly, to me Buffer implies FIFO, things go into one end, wait for other elements to be processed, and then go out the other end.
This waiting is what creates the link with the word “buffer”, it gives you a buffer (time) when processing things.
And so to me, it’s already weird that it contains: both prepend and append, and both drop and dropRight, so it feels weird that the solution is “we already do something which move it away from that idea, and closer to ArrayDequeue, so might as well bring it the whole way”

My point was to say - Buffer interface already provides all the methods for FIFO and LIFO - and most implementations are efficient at both - only ArrayBuffer is an outlier. So yeah the proposal just adds some convenience wrappers that the interface is already well suited to.

[SethTisue]

We discussed this briefly at core. Core has no objections to the proposal broadly. Jamie has clarified the relationship of Buffer to mutable.Seq. Expanding Buffer’s set of operations is okay (yes, even if some of the additions aren’t efficient in some implementations, that ship has already sailed). And making ArrayDeque the default Buffer is good.

On the rest, time just needs to be taken to make sure the details are right (especially on the new operations), and that proper documentation is added, including what the performance guarantees (or lack of guarantees) are.