On Fri, Mar 22, 2024 at 2:20 AM Boqun Feng <boqun.feng@xxxxxxxxx> wrote:
>
> One more extra point from myself only: if one is using Rust for drivers
> or subsystem they are going to take care of it in the future, it's
> totally fine for them to pick coding styles that they feel comfortable,
> I don't want to make people who do the real work feel frustrated because
> "this is how Rust idioms must be", also I don't believe tools should
> restrict people. But in the "kernel" crate (i.e. for core kernel part),
> I want to make it "Rusty" since it's the point of the experiement ("you
> asked for it ;-)).
We should aim to be as consistent as possible for all the kernel, not
just the "core kernel".
Yes, there should be flexibility. In fact, sometimes it is just
impossible, unreasonable, impractical and/or annoying to be
consistent. And, as you say, we should definitely avoid making people
frustrated for inane reasons.
But we should not introduce flexibility for bad reasons either.
And this is the kind of thing that it is very hard to restrict later.
So even if we are a bit "over the top" in some cases now (the current
compiler/Clippy flags could be already arguably so, at times), the
point is to figure out what makes sense to keep long term. In other
words, instead of discussing how to create local coding styles, we
should be discussing what should be changed for everybody (e.g.
because a particular diagnostic may too annoying now, because a style
is found to be better than another like `if ret < 0 ...` vs.
`to_result` and so on).
Cheers,
Miguel
