Received-SPF: pass (google.com: domain of linux-kernel+bounces-73390-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
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> <CANiq72nVkV3+1rt4Mi+Own6KGAzmvR2jf8fFsp9NBu_gy_ob5g@mail.gmail.com>
 <462aad75-4f03-4f8b-ad58-eef429ed2b34@redhat.com>
In-Reply-To: <462aad75-4f03-4f8b-ad58-eef429ed2b34@redhat.com>
From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date: Tue, 20 Feb 2024 17:53:51 +0100
Message-ID: <CANiq72m7-5CuKAKDk=G9sauri_sH0nR2TXi8ye5Eji-qaum3sw@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 4:53=E2=80=AFPM Danilo Krummrich <dakr@redhat.com> =
wrote:
>
> The rational for a convention can't be that it is a convention. Instead
> it should be a convention for an objective reason.

The rationale __for the lint__ is that it is a very established
convention in Rust code.

That is what Clippy is telling you.

You may not agree with the convention (and thus the lint). That is
fine, but it is still a fact that it is the convention, and that is
why I said whoever wrote that Clippy description probably felt that
wording is good enough.

> I'm not saying that we should enforce it otherwise, I just think that we
> should have objective reasons for restrictions.

Again, you seem to be saying we do not have objective reasons.

> However, I also don't see why we should disallow it as long as there is
> no objective reason to do so.

There are objective reasons to do so and we already explained them to you a=
bove:

    https://lore.kernel.org/rust-for-linux/CAH5fLggXiXGA_UWCxqqLhMpXe1kepDv=
2vMG+1jLGaDSzdRHvSw@mail.gmail.com/
    https://lore.kernel.org/rust-for-linux/CANiq72nVkV3+1rt4Mi+Own6KGAzmvR2=
jf8fFsp9NBu_gy_ob5g@mail.gmail.com/

You disagree? Fine, if you can come up with an argument that convinces
us or a good majority of the kernel that uses Rust, then I will
happily apply the patch.

Personally, I don't particularly care (based on style arguments alone)
whether to write `return` or not. But I do care about not wasting time
on litigating particular choices each time somebody does not like one.

> That's actually what the language did already with early-return vs return=
 at
> the end of the function.
>
> I admit that consistent inconsistency is also kinda consistent though. :-=
)
>
> The language has various characteristics, maybe that's why it allows both=
?

Languages may allow a lot of things, but that does not mean we write
the code like IOCCC just because we can.

Nor it does mean that a project should allow every way to write things
either, _especially_ when it is a very widespread convention.

> See above.

I don't see it, sorry. You said you want to be "explicit", but one can
very easily argue you are _not_ being explicit by omitting the
`return` in some cases.

> That's great, although I really don't understand why you think this one i=
s, but
> the other one isn't. What's the difference?

We already told you in this thread several times -- the `return` one
is idiomatic and so on. See the links above.

> I agree, but I also think it should be the other way around. We should ha=
ve good
> examples and an objective rationale for things we restrict.

Why? To me, we should have good examples and an objective rationale
for things where we actually want to deviate from what everybody else
is doing.

Cheers,
Miguel