Vec::with_capacity does not work correctly for zero-sized types

[mistodon]

Calling Vec::with_capacity(N) does not give you a vector with capacity N.

fn main()
{
    let v: Vec<()> = Vec::with_capacity(5);
    assert_eq!(v.capacity(), 5);
}

This fails with:

thread 'main' panicked at 'assertion failed: `(left == right)` (left: `18446744073709551615`, right: `5`)', src/main.rs:4

when running in the playground on stable.

I would expect the capacity to be 5. Logically, I realize the capacity for a zero-sized type is not actually limited, but the docs do say "vec![x; n], vec![a, b, c, d], and Vec::with_capacity(n), will all produce a Vec with exactly the requested capacity."

[cuviper]

This is a consequence of RawVec::cap which explicitly returns usize::MAX for zero-sized types.
And Vec::capacity says "the number of elements the vector can hold without reallocating," which for ZSTs is simply as many as we can count.

Vec::with_capacity says, "The vector will be able to hold exactly capacity elements without reallocating." I guess you could argue whether that "exactly" implies that it will reallocate for a greater number of elements, but there's never any allocation for ZSTs anyway.

IMO the behavior is fine, but the docs could clarify this situation.

[steveklabnik]

I'm happy to modify the docs but would like to know what the libs team thinks.

[alexcrichton]

IIRC with_capacity is not guaranteed to return a vector with exactly that capacity, it's allowed to round up also due to the allocator giving it more memory (or something like that). I think this is just a case where the docs may be able to be more explicit.

[sfackler]

There is reserve_exact, though. Does that handle ZST capacity differently?

[scottmcm]

Even reserve_exact doesn't guarantee exactly:

Note that the allocator may give the collection more space than it requests. Therefore capacity can not be relied upon to be precisely minimal.

This is essentially that situation -- the "nop allocator" said we can hold lots -- so it feels to me like with_capacity should get the same caveat (also seen on shrink_to_fit).

[dtolnay]

The behavior is fine. The docs need to indicate that the capacity will be at least what you requested, with the caveat from reserve_exact.

[steveklabnik]

I'm not sure when this was fixed, but it was:

The collection may reserve more space to avoid frequent reallocations. After calling reserve, capacity will be greater than or equal to self.len() + additional.