-
Notifications
You must be signed in to change notification settings - Fork 24
Description
Proposal
Problem statement
Sometimes it's useful to be able to create empty iterators without needing to first obtain an empty container to then iterate over, some of the existing iterator types implement Default for this #77 but there are still quite a few missing.
Motivating examples or use cases
I'm currently writing a parser for parsing templates for command lines that are already split into a slice of arguments (written using the Default impls I'd like to add):
#[derive(Copy, Clone, Debug, PartialEq, Eq)]
enum Token {
Char(char),
ArgSeparator,
}
#[derive(Clone, Debug, Default)]
struct Tokens<'a> {
current: std::str::Chars<'a>,
rest: std::slice::Iter<'a, &'a str>,
}
impl<'a> Tokens<'a> {
fn new(args: &'a [&'a str]) -> Self {
Self { rest: args, ..Self::default() }
}
}
impl Iterator for Tokens<'_> {
type Item = Token;
fn next(&mut self) -> Option<Self::Item> {
match self.current.next() {
Some(c) => Some(Token::Char(c)),
None => {
self.current = self.rest.next()?.chars();
Some(Token::ArgSeparator)
}
}
}
}
// code that uses Tokens...Solution sketch
implement Default for all iterators where the iterator is constructed from some type that has an obvious default value that's empty. So std::str::Chars should be Default since "" is obviously empty. std::array::IntoIter should not be Default since the array type's default wouldn't be empty unless it has zero length. std::env::Args should not be Default since an obvious default value is the program's arguments which isn't usually empty.
The full list of iterator types: https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#implementors
Iterator implementations I found:
iterator implements Default already
For list, see #656 (comment)
iterator should implement Default
core::ascii::EscapeDefaultcore::char::EscapeDebugcore::char::EscapeDefaultcore::char::EscapeUnicodecore::char::ToLowercasecore::char::ToUppercasecore::char::decode::DecodeUtf16core::error::Sourcecore::ffi::c_str::Bytescore::iter::adapters::array_chunks::ArrayChunkscore::iter::adapters::by_ref_sized::ByRefSizedcore::iter::adapters::cycle::Cyclecore::iter::adapters::filter::Filtercore::iter::adapters::filter_map::FilterMapcore::iter::adapters::flatten::FlatMapcore::iter::adapters::inspect::Inspectcore::iter::adapters::intersperse::Interspersecore::iter::adapters::intersperse::IntersperseWithcore::iter::adapters::map::Mapcore::iter::adapters::map_while::MapWhilecore::iter::adapters::map_windows::MapWindowscore::iter::adapters::peekable::Peekablecore::iter::adapters::scan::Scancore::iter::adapters::skip::Skipcore::iter::adapters::skip_while::SkipWhilecore::iter::adapters::step_by::StepBycore::iter::adapters::take::Takecore::iter::adapters::take_while::TakeWhilecore::iter::adapters::zip::Zipcore::iter::sources::once::Oncecore::iter::sources::once_with::OnceWithcore::option::IntoItercore::option::Itercore::option::IterMutcore::range::iter::IterRangecore::range::iter::IterRangeFromcore::range::iter::IterRangeInclusivecore::result::IntoItercore::result::Itercore::result::IterMutcore::slice::ascii::EscapeAsciicore::slice::iter::ArrayWindowscore::slice::iter::ChunkBycore::slice::iter::ChunkByMutcore::slice::iter::Chunkscore::slice::iter::ChunksExactcore::slice::iter::ChunksExactMutcore::slice::iter::ChunksMutcore::slice::iter::RChunkscore::slice::iter::RChunksExactcore::slice::iter::RChunksExactMutcore::slice::iter::RChunksMutcore::slice::iter::RSplitcore::slice::iter::RSplitMutcore::slice::iter::RSplitNcore::slice::iter::RSplitNMutcore::slice::iter::Splitcore::slice::iter::SplitInclusivecore::slice::iter::SplitInclusiveMutcore::slice::iter::SplitMutcore::slice::iter::SplitNcore::slice::iter::SplitNMutcore::slice::iter::Windowscore::str::iter::Bytescore::str::iter::CharIndicescore::str::iter::Charscore::str::iter::EncodeUtf16core::str::iter::EscapeDebugcore::str::iter::EscapeDefaultcore::str::iter::EscapeUnicodecore::str::iter::Linescore::str::iter::LinesAnycore::str::iter::MatchIndicescore::str::iter::Matchescore::str::iter::RMatchIndicescore::str::iter::RMatchescore::str::iter::RSplitcore::str::iter::RSplitNcore::str::iter::RSplitTerminatorcore::str::iter::Splitcore::str::iter::SplitAsciiWhitespacecore::str::iter::SplitInclusivecore::str::iter::SplitNcore::str::iter::SplitTerminatorcore::str::iter::SplitWhitespacecore::str::lossy::Utf8Chunksalloc::collections::binary_heap::IntoIterSortedalloc::collections::btree::set::Differencealloc::collections::btree::set::Intersectionalloc::collections::btree::set::SymmetricDifferencealloc::collections::btree::set::Unionalloc::collections::linked_list::ExtractIfalloc::collections::vec_deque::into_iter::IntoIteralloc::string::IntoCharsproc_macro::token_stream::IntoIterstd::collections::hash::set::Differencestd::collections::hash::set::Intersectionstd::collections::hash::set::SymmetricDifferencestd::collections::hash::set::Unionstd::os::unix::net::ancillary::Messagesstd::os::windows::ffi::EncodeWidestd::path::Ancestorsstd::path::Componentsstd::path::Iterstd::process::CommandArgsstd::process::CommandEnvs
iterator could implement Default but it might make the rest of the iterator slower (e.g. adding a conditional in Drop)
alloc::collections::binary_heap::Drainalloc::collections::binary_heap::DrainSortedalloc::collections::btree::map::ExtractIfalloc::collections::btree::set::ExtractIfalloc::collections::vec_deque::drain::Drainalloc::string::Drainalloc::vec::drain::Drainalloc::vec::extract_if::ExtractIfalloc::vec::splice::Splicestd::collections::hash::map::Drainstd::collections::hash::map::ExtractIfstd::collections::hash::set::Drainstd::collections::hash::set::ExtractIfstd::os::unix::net::ancillary::ScmCredentialsstd::os::unix::net::ancillary::ScmRights
iterator shouldn't implement Default
core::iter::sources::from_coroutine::FromCoroutinecore::iter::sources::from_fn::FromFncore::iter::sources::repeat::Repeatcore::iter::sources::repeat_n::RepeatNcore::iter::sources::repeat_with::RepeatWithcore::iter::sources::successors::Successorsstd::env::Argsstd::env::ArgsOsstd::env::SplitPathsstd::env::Varsstd::env::VarsOsstd::fs::ReadDirstd::io::Bytesstd::io::Linesstd::io::Splitstd::net::tcp::Incomingstd::net::tcp::IntoIncomingstd::os::unix::net::listener::Incoming
iterator could implement Default but we maybe shouldn't
core::ops::range::RangeFromcore::ops::range::RangeInclusivestd::sync::mpmc::IntoIterstd::sync::mpmc::Iterstd::sync::mpmc::TryIterstd::sync::mpsc::IntoIterstd::sync::mpsc::Iterstd::sync::mpsc::TryIter
Alternatives
Manually construct iterators from a manually-obtained empty source type and have to implement Default manually.
Links and related work
We did some of this before in #77 but didn't end up handling all the iterator types.
What happens now?
This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.
Possible responses
The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):
- We think this problem seems worth solving, and the standard library might be the right place to solve it.
- We think that this probably doesn't belong in the standard library.
Second, if there's a concrete solution:
- We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
- We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.