Variant with runtime fixed capacity

[Icxolu]

Would you accept a PR that adds a variant of CircularBuffer that has a runtime fixed capacity instead of compile-time fixed capacity?

That variant would use a boxed slice (Box<MaybeUninit<T>>) as backing storage instead of an array und thus would only be available under the use_std feature flag. I think almost all method implementations could be shared between the variants using a macro.

[andreacorbellini]

Hi, big apologies for the long delay in responding to this. The short answer is: yes, I'd be welcoming a heap-based implementation where the capacity is supplied at runtime instead of compile time. In fact, I would have probably added it from the very first release if only I could have come up with a good name for the struct.

A couple notes:

• The backing storage should perhaps be a NonNull<T> (created via Layout::array + Allocator::allocate) or a Box<[MaybeUninit<T>]> (created via Box::new_uninit_slice). The latter would probably be the easiest approach because the existing CircularBuffer implementation can be reused without significant changes.

  Using a Box<MaybeUninit<T>> wouldn't work because that would hold a single element only.

• I agree that macros is a good approach to make the two variants share the same code. I would most likely have followed the same approach. On that respect, perhaps it's worth changing all usages of N in the code with self.capacity().

• Adapting tests will probably be the most annoying part. Perhaps an easy way to do it is to write all the tests in a big macro and then expand the macro in two test submodules: static and dynamic.

• I believe that this feature could be implemented in no_std mode by using the alloc crate, however this can be left as a future improvement. For now I agree that we can make this struct available only with the use_std feature, and then improve it at a later time.

• For zero-sized structs (ZST), no allocation should happen (this can be left as a future improvement).

I'm happy to help shaping & coding this feature if needed. My time in these months is a bit unpredictable (which is the reason why it took me so long to respond), but if you'd like me to collaborate on this, please let me know.

[Icxolu]

Hi, thanks for the feedback and no worries about the response time, stuff happens.

... Box<[MaybeUninit<T>]> (created via Box::new_uninit_slice). The latter would probably be the easiest approach because the existing CircularBuffer implementation can be reused without significant changes.

Yeah, i actually meant this one. Seems like I typoed it 🙃

I did a proof of concept a while ago, which I can probably clean up and polish a bit, and then submit as a PR. I also struggled with the naming 😆, for now I named it CircularBufferAlloc but maybe there is something better still. It seem like naming is always the hardest problem 🤣.

I like the idea about splitting the tests into two submodules. I think we can use the same for the actual implementations (and maybe reexport the structs for easy access in the crate root).