Re: [PATCH RESEND] block, rust: simplify validate_block_size() function

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Tue, Sep 03, 2024 at 09:30:53PM +0200, Miguel Ojeda wrote:
> On Tue, Sep 3, 2024 at 9:00 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > If you want to keep dividing into Rust-land and C-land I'm afraid you
> > will have 2 islands that do not talk to each other. I really want to be
> 
> We are not trying to divide the Rust and C side, quite the opposite.
> That should be obvious since dividing both sides only hurts the
> project to begin with.
> 
> > able to parse the things quickly and not constantly think if my Rust is
> > idiomatic enough or I could write the code in a more idiomatic way with
> > something brand new that just got off the nightly list and moved into
> > stable.
> 
> If a feature is in the minimum support version we have for Rust in the
> kernel, and it improves the way we write code, then we should consider
> taking advantage of it.
> 
> Now, that particular function call would have compiled since Rust 1.35
> and ranges were already a concept back in Rust 1.0. So I am not sure
> why you mention recently stabilized features here.

I was talking in general, not about this exact case, sorry if I was
unclear. But in general I personally have this issue with Rust and to
extent also with C++ where I constantly wonder if my code is "idiomatic
enough" or if it looks obsolete because it is "only" C++14 and not 17
or 20.

With C usually have no such concerns which allows me to concentrate on
different things.

> 
> For this particular case, I don't think it matters too much, and I can
> see arguments both ways (and we could introduce other ways to avoid
> the reference or swap the order, e.g. `n.within(a..b)`).
> 
> > This is a private function and an implementation detail. Why does it
> > need to be exposed in documentation at all?
> 
> That is a different question -- but even if it should be a private
> function, it does not mean documentation should be removed (even if
> currently we do not require documentation for private items).

I think exposing documentation for private function that can change at
any time and is not callable from outside has little value. That does
not mean that comments annotating such function have no value. But they
need to be taken together with the function code, and in this case
Alexey's concern about comments like "this increments that by 1"
becomes quite valid.

Thanks.

-- 
Dmitry