From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Gary Guo" <gary@garyguo.net>
Cc: "Miguel Ojeda" <miguel.ojeda.sandonis@gmail.com>,
"Lorenzo Delgado" <lnsdev@proton.me>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun@kernel.org>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Tamir Duberstein" <tamird@kernel.org>,
"Onur Özkan" <work@onurozkan.dev>,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
"Thorsten Blum" <blum@kernel.org>,
"Francis Laniel" <laniel_francis@npnm.eu>
Subject: Re: [PATCH v3 1/2] rust: non_empty: add NonEmpty
Date: Thu, 15 Oct 2026 21:43:44 +0900 [thread overview]
Message-ID: <DM5F615QE0QH.MV46NZSC3TR0@nvidia.com> (raw)
In-Reply-To: <DM4MPF17NSQL.2IOMXIQEVINKR@garyguo.net>
On Wed Oct 14, 2026 at 11:25 PM JST, Gary Guo wrote:
> On Wed Oct 14, 2026 at 12:55 PM BST, Miguel Ojeda wrote:
>> On Wed, Oct 14, 2026 at 10:30 AM Lorenzo Delgado <lnsdev@proton.me> wrote:
>>>
>>> +/// A container that can report whether it holds any element.
>>> +///
>>> +/// The result must not change while the container is only reachable through a shared reference.
>>> +///
>>> +/// Unsafe code may only rely on the result for a container type whose implementation it trusts,
>>> +/// such as the ones in this module, since a safe implementation can return anything.
>>> +pub trait IsEmpty {
>>> + /// Returns `true` if the container holds no element.
>>> + fn is_empty(&self) -> bool;
>>> +}
>>
>> Do we need this to be a safe trait? If it is unsafe, then we can
>> simplify the invariant and more easily think about the type, like
>> other `Non*`s, no?
>
> I think in this case the meaning of "empty" depends on the container itself.
> Unsafe code that relies on "is_empty" would be the `NonEmpty<Container>` itself,
> so it just needs to trust itself (as boundary of unsafe is module level).
>
> I think of almost all of the text above can be removed. The invariant of
> `NonEmpty` can just be "`IsEmpty::is_empty` has returned true" and how it is
> interpreted is up to the container type.
Is `IsEmpty` actually useful? It needs to be implemented for every
container we want to wrap with essentially the same boilerplate code,
which looks a bit overkill to me. Couldn't we just do:
impl<T, C: Deref<Target = [T]>> NonEmpty<C>
and have a single constructor method that supports all container types
by reusing the slice's `is_empty` method?
That way we could get rid of `IsEmpty` entirely. That would limit
`NonEmpty` to types that directly deref to `[T]`, but I guess we are
going to use it on slices most of the time, with the exception of when
we want to return an owned container that is not empty, and those we
have already deref to a slice.
next prev parent reply other threads:[~2026-10-15 12:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 8:30 [PATCH v3 0/2] rust: add NonEmpty Lorenzo Delgado
2026-10-14 8:30 ` [PATCH v3 1/2] rust: non_empty: " Lorenzo Delgado
2026-10-14 11:55 ` Miguel Ojeda
2026-10-14 14:25 ` Gary Guo
2026-10-15 12:43 ` Alexandre Courbot [this message]
2026-10-15 14:02 ` Gary Guo
2026-10-15 14:33 ` Alexandre Courbot
2026-10-15 14:08 ` Miguel Ojeda
2026-10-14 8:30 ` [PATCH v3 2/2] rust: uaccess: use NonEmpty in strcpy_into_buf() Lorenzo Delgado
2026-10-15 13:06 ` Alexandre Courbot
2026-10-15 14:04 ` Gary Guo
2026-10-15 12:57 ` [PATCH v3 0/2] rust: add NonEmpty Alexandre Courbot
2026-10-15 14:08 ` Gary Guo
2026-10-15 14:11 ` Miguel Ojeda
2026-10-15 14:35 ` Alexandre Courbot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DM5F615QE0QH.MV46NZSC3TR0@nvidia.com \
--to=acourbot@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=blum@kernel.org \
--cc=boqun@kernel.org \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=gary@garyguo.net \
--cc=laniel_francis@npnm.eu \
--cc=linux-kernel@vger.kernel.org \
--cc=lnsdev@proton.me \
--cc=lossin@kernel.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tamird@kernel.org \
--cc=tmgross@umich.edu \
--cc=work@onurozkan.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.