Re: [PATCH] rust: add a ring buffer implementation

[Daniel Almeida]

> On 17 Feb 2026, at 16:10, Andreas Hindborg <a.hindborg@xxxxxxxxxx> wrote:
> 
> "Danilo Krummrich" <dakr@xxxxxxxxxx> writes:
> 
>> On Tue Feb 17, 2026 at 11:02 AM CET, Andreas Hindborg wrote:
>>> We can change the code down the road, no problem. It's not set in stone
>>> just because we merge it without generic alloc support.
>> 
>> Just to avoid any ambiguity, we should merge it with generic allocator support,
>> but aiming for arbitrary I/O backend support would be a bit too much.
> 
> Right.
> 
>> 
>>> Perhaps one could imagine a simple API like in this patch being provided
>>> by a configurable implementation behind the scenes.
>> 
>> Yeah, in the future we could implement the system memory specific one with a
>> type alias on top of the I/O backend agnostic one. But it remains to see if this
>> will actually work out properly or if it's even worth in terms of
>> maintainability etc.
>> 
>> (E.g. one of the limitations that I've mentioned already is that I/O backends do
>> not support growing and shrinking of the backing memory. And I'm not yet sure if
>> they ever should.)
> 
> This particular ringbuffer* implementation does not support changing the
> capacity after initialization, so I don't see that being an issue. For
> applications that need to scale the size of the ring dynamically, we
> could have another type. Or a generic parameter, if that makes sense.

Maybe at the risk of sounding a bit silly with the oversimplification here, but
isn’t this a mere problem of offering specific impls for backends where you
can reallocate? i.e.:

impl<T> RingBuffer<T, SomeActualBackend> {
  fn force_push() { ... } // realloc if needed; only implemented for backends where this is possible
}

> 
> Best regards,
> Andreas Hindborg
> 
> 
> * VecDeque? This kind of structure has always been a ring to me.