Feature request: Construct a fully initialized SliceDeque

[niklasf]

Feature request: A shortcut to create a fully initialized SliceDeque with a given minimum capacity.

---

Here's my use case, in case this is an XY problem. SliceDeque is useful as a buffer for file I/O. In particular:

file.read(unsafe { sdeq.tail_head_slice() })?;

However:

[...] It is your responsibility to make sure that buf is initialized before calling read. [...]

So I simply start by

let sdeq: SliceDeque<u8> = SliceDeque::with_cacacity(MIN_BUFFER_SIZE);
unsafe {
    let uninitialized = sdeq.tail_head_slice();
    ptr::write_bytes(uninitialized.as_mut_ptr(), 0, uninitialized.len());
}

// As long as the slice deque is never grown, it can now be treated as
// completely initialized.

[gnzlbg]

Feature request: A shortcut to create a fully initialized SliceDeque with a given minimum capacity

Why doesn't sdeq![your_value; N] work for you ?

[niklasf]

I believe the SliceDeque is allowed to allocate capacity for more than N items, so tail_head_slice() could still contain some uninitialized memory.

[gnzlbg]

That's always the case for any collection, e.g., Vec::with_capacity(N) "allocates memory for at least N elements" and it often allocates memory for more.

[niklasf]

Fair enough.

I guess having a version of SliceDeque with a guaranteed initialized tail_head_slice (e.g. zeroed) is too much of an edge case.

[gnzlbg]

@niklasf I think I misunderstood your problem. You only want a method to initialize the content of the tail_head_slice ?

[niklasf]

Yes. And I'd like to pay the cost only once (when the SliceDeque is initialized, or when it grows). In the file I/O example I am happy with garbage in the tail_head_slice, as long as it is at least initialized memory.

I believe this would be sound for u8 and other Copy types, but not in general, which makes me think this use case is wierd and probably not too common.

[gnzlbg]

See #76, which is related.

[gnzlbg]

So one thing is that, as long as you never exceed the capacity of the SliceDeque, it won't reallocate. However, if you are using .extend, .push_X, etc. methods, the only way to tell whether a reallocation happened is to query the capacity before, and query the capacity afterwards, and compare that they did not change - and if the capacity changed, then you need to explicitly zero the tail_head again (it would be an unreasonable thing to do implicitly, but you could write a small wrapper over SliceDeque that always does this for you).

For initialization, what you are currently doing is reasonable with the provided API. I'm not sure which API shall SliceDeque provide instead, but I'm open to suggestions. The usecase is indeed a bit niche, so if you do this often, you could just write a function that does this right for you (it doesn't necessarily need to be a method).

(I'm re-opening the issue because I misunderstood your problem, and I need to give an API for this more thought).

[niklasf]

Looking at this old request again, given .extend() etc. this would be a pretty fragile invariant, so it might just not be a good fit for this crate.