linux-kernel - Re: [PATCH v10 2/2] rust: xarray: Add an abstraction for XArray

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAJ-ks9kxkd5bgbDuSwEru7RAmxp5D4HXrJNe-m=2EFm+_Ep9Ag@mail.gmail.com>
Date: Tue, 3 Dec 2024 11:01:13 -0500
From: Tamir Duberstein <tamird@...il.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Alice Ryhl <aliceryhl@...gle.com>, Danilo Krummrich <dakr@...nel.org>, 
	Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, 
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <benno.lossin@...ton.me>, Andreas Hindborg <a.hindborg@...nel.org>, 
	Trevor Gross <tmgross@...ch.edu>, Maíra Canal <mcanal@...lia.com>, 
	Asahi Lina <lina@...hilina.net>, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v10 2/2] rust: xarray: Add an abstraction for XArray

On Tue, Dec 3, 2024 at 10:22 AM Miguel Ojeda
<miguel.ojeda.sandonis@...il.com> wrote:
>
> On Tue, Dec 3, 2024 at 4:00 PM Tamir Duberstein <tamird@...il.com> wrote:
> >
> > I prefer to be explicit, unless there's guidance on this somewhere?
>
> I like explicitness in general, but do you think there is an advantage
> for things in the prelude?
>
> I am asking because I am considering adding more things there, e.g. I
> have a series to be sent to add the `ffi::c_*` types -- having things
> like those in the prelude reduces the noise in imports that everyone
> knows about (and that nobody should be tempted to alias anyway), makes
> things more consistent (because then every use is unqualified vs. the
> mix we have now) and generally the code looks easier to read to focus
> on the other things that may be less common.

I agree with these goals, but I personally disprefer the prelude
approach. Probably the most common misuse involves traits in the
prelude, where importing them can change function call resolution.
It's very likely that this isn't a problem with the prelude currently,
but it also doesn't seem to be used consistently everywhere. I don't
feel very strongly, so if there's a mandate to use it then I'll do so.