Received-SPF: pass (google.com: domain of linux-kernel+bounces-73625-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <d88bfe23-6fbd-4bb9-8878-3ccc63b97ddd@redhat.com>
Date: Tue, 20 Feb 2024 20:55:41 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4] rust: str: add {make,to}_{upper,lower}case() to
 CString
Content-Language: en-US
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.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
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>
 <CANiq72n06BCWuHoWbQBrODqgfH8ZGEc6rLhMu86UiYpKdjO3PA@mail.gmail.com>
From: Danilo Krummrich <dakr@redhat.com>
Organization: RedHat
In-Reply-To: <CANiq72n06BCWuHoWbQBrODqgfH8ZGEc6rLhMu86UiYpKdjO3PA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 2/20/24 16:45, Miguel Ojeda wrote:
> On Tue, Feb 20, 2024 at 3:53 PM 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 really know
>> what's the best way to do that. We could pass '-Aclippy::' to the compiler...
> 
> 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?

Nothing, but I also never wrote that wanting to be consistent is not objective.

I wrote that omitting the return statement is more "rusty" isn't an objective
argument in my opinion.

Maybe the misunderstanding is that consistent doesn't necessarily mean to do what
everyone else does. Consistency has a scope. For instance, we can also be consistent
with something that everyone else does differently, like linked lists throughout the
kernel.

> 
>> 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 just annoy
>> people and lead to less ideal code for the project. And I intentionally say "for
>> the project", since this context is important.
> 
> Who is *blindly* following formatters and linters? We don't have
> objective reasons?

This doesn't seem to be a "straight up" question. Hence, for the following I will
assume that you feel like I said those things about you.

First of all, I said that *we* (as a community) should not blindly follow formatters
and linters and should have objective reasons for language restrictions in general.
I never said anyone specific is doing that. Claiming that I did so, *would* be a straw
man.

Furthermore I was questioning two of the restrictions we already have and was asking
for an objective rationale for those, since the clipply documentation does not provide
an objective rationale in my opinion.

Generally speaking, I don't think there is anything wrong in saying that I think some
argument isn't objective (even if I'd be proven wrong). This is by far not the
same as saying someone has no objective reasons (in general). This would be a straw man
as well.

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

I already had the feeling from your answer in the other thread. But, unfortunately,
I don't understand why. If the above did not convince you otherwise, can you please
explain?

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