Received-SPF: pass (google.com: domain of linux-kernel+bounces-73270-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240219163915.2705-1-dakr@redhat.com> <20240220093541.280140-1-aliceryhl@google.com>
 <e543b270-dea7-477a-b83d-62129d4ac708@redhat.com> <CAH5fLggXiXGA_UWCxqqLhMpXe1kepDv2vMG+1jLGaDSzdRHvSw@mail.gmail.com>
 <19d0a4a9-85bb-4b9e-96b0-338adebc90e5@redhat.com>
In-Reply-To: <19d0a4a9-85bb-4b9e-96b0-338adebc90e5@redhat.com>
From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date: Tue, 20 Feb 2024 16:45:44 +0100
Message-ID: <CANiq72n06BCWuHoWbQBrODqgfH8ZGEc6rLhMu86UiYpKdjO3PA@mail.gmail.com>
Subject: Re: [PATCH v4] rust: str: add {make,to}_{upper,lower}case() to CString
To: Danilo Krummrich <dakr@redhat.com>
Cc: Alice Ryhl <aliceryhl@google.com>, a.hindborg@samsung.com, alex.gaynor@gmail.com, 
	benno.lossin@proton.me, bjorn3_gh@protonmail.com, boqun.feng@gmail.com, 
	gary@garyguo.net, linux-kernel@vger.kernel.org, ojeda@kernel.org, 
	rust-for-linux@vger.kernel.org, wedsonaf@gmail.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 20, 2024 at 3:53=E2=80=AFPM Danilo Krummrich <dakr@redhat.com> =
wrote:
>
> Just to clarify, I did not say anything else. As mentioned, I think those
> should not even be warnings.

Well, for things like the `return` one, I find it unlikely it will change.

And for other things that there are 2 ways of doing it, what we
typically want is to have one way of doing it, rather than allowing
both ways.

> I'm happy to do that. We should define the scope for that though. I think=
 this
> should be set globally, or at least not per crate. However, I don't reall=
y know
> what's the best way to do that. We could pass '-Aclippy::' to the compile=
r...

The scope is already defined -- it is global, precisely because we
want to keep all kernel code as consistent as possible.

> Is there any objective reason not to be allowed to be explicit here?

What is not objective about wanting to be consistent? How is your
argument objective if ours isn't?

> Well, I generally agree. However, I'm clearly against *blindly* following
> formatters and linters.
>
> Forcing guidelines we don't have objective reasons for will otherwise jus=
t annoy
> people and lead to less ideal code for the project. And I intentionally s=
ay "for
> the project", since this context is important.

Who is *blindly* following formatters and linters? We don't have
objective reasons?

I don't appreciate the way you are wording things here.

Does it actually lead to "less ideal code", or the opposite?

Cheers,
Miguel