Re: [PATCH v4 2/3] Adds Rust Bitmap API.

[Miguel Ojeda]

On Wed, Mar 19, 2025 at 11:40 AM Alice Ryhl <aliceryhl@xxxxxxxxxx> wrote:
>
> Rewording `new` to `alloc` seems reasonable.
>
> As for "drop", that word is special. It's the destructor that is called
> automatically when the bitmap goes out of scope - you can't call it
> directly. It must be called "drop".

Alice obviously knows the following, but for so that Yury has the
context: `new` is the typical name in Rust for the "primary"
constructor, so that is probably Burak picked it, e.g. see:

    https://rust-lang.github.io/api-guidelines/predictability.html#constructors-are-static-inherent-methods-c-ctor

Constructors in Rust are not special, and you can use any names (and
can return errors etc., unlike C++).

So people use `new` by convention since it is what others may look for
first in the documentation. It is especially nice if there is only a
single constructor, but not a big deal.

> But the confusion with "no set bits" seems like a good reason to silence
> that warning for bitmap.

Yeah, if a lint is giving trouble, please just disable it.

And if we need to disable it in quite a few places, we may just want
to disable it globally.

> We can still call the method __set_bit if you think that is best, but
> because underscore prefixes usually mean something different in Rust, I
> wonder if we should use slightly different names in Rust. Thoughts?

I would really prefer if we do our best to avoid underscores in Rust,
especially for non-private APIs.

In Linux we abuse `_+names` a bit sometimes to avoid writing a proper
name/prefix/suffix for the different variations of operations, and I
don't think it is a good idea to mimic that for non-private APIs. I
mean, for static single variations, it is OK-ish, but other cases are
not really great.

Worse, if we start doing that in Rust, we may start doing it for
things that do not even need to mimic a C API name...

Now, I know it is painful to have a different name than C, so it is a
trade-off. And sometimes coming up with names is difficult, too.

The underscore implying "possibly unused" is not too important for
`pub` APIs I think, since the compiler wouldn't warn about those
anyway, no? But for non-`pub` ones, I agree it is one more reason to
avoid it.

Cheers,
Miguel