Skip to content

Tracking Issue for (into_)inner() methods on iterator adapters #103302

@krtab

Description

@krtab

Feature gate: #![feature(inner_adaptor)]

This is a tracking issue for adding two methods to each iterator adapter containing "only one" adaptor. This two methods allow accessing the inner iterator of the adapter either through non-mutable reference or by consuming the adaptor. A mutable accessor is purposefully not included to prevent logic error and avoid "confusing" the adaptor.

The use case I had was that I wanted to wrap a xmlparser::Tokenizer in a Peekable and a Filter but still have access to some of its method (that are only available in my fork of it and currently being merged). This method are not specifically iterator related but allow access to the inner UTF-8 stream of the tokenizer for example.

In more details, the current choice on whether to implement this method is:

Implemented

  • Cloned
  • Copied
  • Enumerate
  • Filter
  • FilterMap
  • Inspect
  • Intersperce
  • MapWhile
  • Map
  • Peekable: Can be confusing because the inner iterator is "one step further" if it has been peeked. Would documentation be enough?
  • Rev
  • Scan
  • Skip_While
  • Skip
  • StepBy
  • TakeWhile
  • Take
  • Zip: has two iterators so one by-ref accessor for each and one conssuming accessor returning a tuple.

Not implemented

  • chain: Has two iterators
  • cycle: Unclear which iterator this should refer to
  • Fuse: Would not make sense when fused, except if returning Option but then the API becomes a bit confusing compared to others

Unclear

  • array_chunks: Could lead to confusion depending on how the underlying iterator is consummed
  • by_ref_sized: Unclear if meant to be used publicly at some point
  • Flatten: Unclear if it would make sense to return the underlying "top-level" iterator

Public API

The basic API is akin to:

//
use std::iter::map

pub struct Map<I,F>;


impl<I, F> Map<I, F> {
    pub fn inner(&self) -> &I;
    pub fn into_inner(self) -> I {}
}

but has some adaptations depending on the case.

Steps / History

Most of the work that remains centers around whether to implement it for cases that can be confusing, and under what documentation constraints.

Unresolved Questions

  • Decide what to do with Peekable
  • Decide what to do with Flatten
  • Decide what to do with ByRefSized
  • Decide what to do with ArrayChunks

Zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/122652-new-members/topic/.5BPre.20RFC.5D.20.28into_.29inner.28.29.20for.20Iterator.20Adapters

Footnotes

  1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCT-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions