On Tue, Sep 3, 2024 at 9:00 PM Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> 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. 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). Cheers, Miguel
