For most use cases of ring-buffers, the capacity used is very important; it must be exactly equal to some application-specific value, or at least greater than or equal to that value. Having a default capacity thus doesn't make much sense. I understand it's useful to have FromIterator available, which requires some kind of default, but since the capacity can't be specified in .collect() (at least for AllocRingBuffer), it shouldn't be a part of the RingBufferExt trait.
On the other hand, it would constitute a breaking change; a generic fn foo<T: RingBufferExt<U>, U>() is allowed to assume that T: FromIterator, and changing RingBufferExt would break that guarantee. It depends upon how often this is used in dependent crates.
For most use cases of ring-buffers, the capacity used is very important; it must be exactly equal to some application-specific value, or at least greater than or equal to that value. Having a default capacity thus doesn't make much sense. I understand it's useful to have
FromIteratoravailable, which requires some kind of default, but since the capacity can't be specified in.collect()(at least forAllocRingBuffer), it shouldn't be a part of theRingBufferExttrait.On the other hand, it would constitute a breaking change; a generic
fn foo<T: RingBufferExt<U>, U>()is allowed to assume thatT: FromIterator, and changingRingBufferExtwould break that guarantee. It depends upon how often this is used in dependent crates.