From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Danilo Krummrich" <dakr@kernel.org>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Joel Fernandes" <joelagnelf@nvidia.com>,
"John Hubbard" <jhubbard@nvidia.com>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] rust: alloc: implement `extend` for `Vec`
Date: Wed, 23 Apr 2025 10:02:58 +0900 [thread overview]
Message-ID: <D9DM3AR3FUAF.6JSNSB9WAJ4T@nvidia.com> (raw)
In-Reply-To: <aAfL-e6qA9oBce5t@cassiopeiae>
On Wed Apr 23, 2025 at 2:03 AM JST, Danilo Krummrich wrote:
>> Well, that turned out to be an interesting rabbit hole.
>>
>> Leveraging the existing traits seems a bit difficult:
>>
>> - `ExactSizeIterator` cannot be implemented for adapters that increase the
>> length of their iterators, because if one of them is already `usize::MAX` long
>> then the size wouldn't be exact anymore. [1]
>>
>> - And `TrustedLen` cannot be implemented for adapters that make an iterator
>> shorter, because if the iterator returns more than `usize::MAX` items (i.e.
>> has an upper bound set to `None`) then the adapter can't predict the actual
>> length. [2]
>
> Why is this a problem for the above implementation of Vec::extend()?
>
> I just looked it up and it seems that std [1] does the same thing. Do I miss
> anything?
>
> [1] https://github.com/rust-lang/rust/blob/master/library/alloc/src/vec/spec_extend.rs#L25
The problem I see is that if you try and do something like:
vec.extend((0..10).into_iter().skip(2));
with the standard library, then the use of `skip` will remove the
`TrustedLen` implementation from the resulting iterator and
`extend_desugared` will be called instead of `extend_trusted`, which
could add some unwanted (and unexpected) overhead.
If we want an implementation of `extend` as simple as "confidently
increase the length of the vector and copy the new items into it, once",
then we need a trait that can be implemented on both shrinking and
extending adapters. Anything else and we might trick the caller into a
code path less efficient than expected (i.e. my original version, which
generates more core even for the obvious cases that are `extend_with`
and `extend_from_slice`). Or if we rely on `TrustedLen` solely in the
kernel, then `extend` could not be called at all with this particular
iterator.
There is also the fact that `TrustedLen` is behind a nightly feature,
which I guess is another obstacle for using it.
next prev parent reply other threads:[~2025-04-23 1:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-06 13:01 [PATCH v3] rust: alloc: implement `extend` for `Vec` Alexandre Courbot
2025-04-07 11:01 ` Danilo Krummrich
2025-04-08 13:34 ` Alexandre Courbot
2025-04-21 8:15 ` Alexandre Courbot
2025-04-22 17:03 ` Danilo Krummrich
2025-04-23 1:02 ` Alexandre Courbot [this message]
2025-04-23 8:51 ` Alice Ryhl
2025-04-23 9:40 ` Alexandre Courbot
2025-04-23 16:03 ` Boqun Feng
2025-04-24 11:50 ` Alice Ryhl
2025-04-24 13:36 ` Boqun Feng
2025-04-23 9:47 ` Danilo Krummrich
2025-04-23 13:15 ` Alexandre Courbot
-- strict thread matches above, loose matches on Subject: below --
2025-04-07 16:33 Benno Lossin
2025-04-08 14:00 ` 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=D9DM3AR3FUAF.6JSNSB9WAJ4T@nvidia.com \
--to=acourbot@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=joelagnelf@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/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.