Re: [PATCH v9 8/9] rust: id_pool: do not round capacity up to BitmapVec::MAX_INLINE_LEN

[Burak Emir]

On Fri, Oct 9, 2026 at 4:07 PM Alexandre Courbot <acourbot@xxxxxxxxxx> wrote:
>
> On Fri Oct 9, 2026 at 12:47 AM JST, Yury Norov wrote:

> > If you still think that you need 0-length bitmaps in Rust, can you please
> > give the clear and thorough explanation why rust needs those 0-length
> > bitmaps. Are there any in-kernel examples? Any language concepts requiring
> > it? If not, it's still a NAK.
>
> I don't know of an in-kernel example, but please look at the
> `bitmap_vec_new` test which has been here since the API was initially
> merged last year: the first thing it does is create a zero-sized bitmap.

Well, yeah: I wanted the behavior that the implementation rounds up
documented so it can be recognized as intentional.
Later, the `new_inline` method was added, which is a clearer way to
get the largest non-allocating BitmapVec.

I think the problem in this discussion is that we want to treat
capacity like length, which is maybe suggested by the BitmapVec name
and its len method.

With the minimum capacity behavior documented, it is as if we have a
specification right now that no IdPool instances can ever have less
capacity than BitmapVec::MAX_INLINE_LEN bits. This patch here proposes
to change that.

It is not clear though why client code would be happy about *less capacity*?

In other words, why should the client of the IdPool have the right to
control the *exact* initial capacity, even if it is below documented,
free-of-charge minimum capacity?

The IdPool, despite being backed by a BitmapVec, is not meant to be
used like a vector: it does not grow by itself but client code calls
grow and shrink explicitly, and client code has no control over how
much that growing and shrinking happens.

Like, you cannot grow to 65 and expect to get a capacity 65. So why
insist on exact small sizes?

> It is also easy to imagine a user starting with an empty pool and
> growing it on-demand. Having the ability to create a zero-sized pool is
> convenient to avoid special-casing user code, and in this case I'd say
> expected, just like you can create a zero-sized vector. Again a size of
> zero does not trigger anything that a larger capacity cannot trigger, so
> I don't see a reason to forbid it.

With an initial capacity of minimum MAX_INLINE_LEN capacity, it is not
about forbidding, it is that the added capacity already comes for
free.
You could say "not enabling" instead of "forbidding", but pretending
that the capacity is somehow not there does not seem to buy us
anything.

Do the other patches in this series need this, or can we just drop this patch?
If they do, maybe a demonstration of how significant the special-case
handling is that can be avoided with the exact small capacity could be
part of the commit message?

Cheers,
Burak