Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document that .iter() has an element type of &T #25928

Closed
Wilfred opened this issue May 31, 2015 · 6 comments
Closed

Document that .iter() has an element type of &T #25928

Wilfred opened this issue May 31, 2015 · 6 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@Wilfred
Copy link
Contributor

Wilfred commented May 31, 2015

The docs for Vec::iter show the following type:

fn iter(&self) -> Iter<T>

As a result, I was puzzled that the following doesn't work:

let bar: Vec<&str> = vec!["a", "b", "c", "b"].iter().collect();

It turns out that that Iter implements an iterator with element type &T. On the Iter docs page we see type Item = &'a T but it's easy to overlook.

I think it would be worth adding a line to Vec::iter's documentation to say:

Iterator element type is &T.

This is the approach taken in itertools docs (example) and I think it helps significantly.

@steveklabnik
Copy link
Member

I'm generally not a fan, as text is hard to track with changes. I'd rather see rustdoc grow support for something like this if if's truly useful. I'm not sure how common this misunderstanding is.

@steveklabnik steveklabnik added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label May 31, 2015
@bluss
Copy link
Member

bluss commented May 31, 2015

I'm a fan of this. I think the iterator element type is only obvious when you already know rust quite well, and it answers one of the single most important questions missing from the function signature.

@Gankra
Copy link
Contributor

Gankra commented May 31, 2015

Ideally all these interfaces should just say -> impl Iterator<&T> or
whatever that future syntax is.

On Sun, May 31, 2015 at 11:33 AM, bluss notifications@github.com wrote:

I'm a fan of this. I think the iterator element type is only obvious when
you already know rust quite well, and it answers one of the single most
important questions missing from the function signature.


Reply to this email directly or view it on GitHub
#25928 (comment).

@bluss
Copy link
Member

bluss commented Jun 1, 2015

Yes but that's far future right now.

I'm wondering what we are going to do about multiple traits. I mean, -> impl Iterator<&T> doesn't describe all we need from it, we need something like -> impl DoubleEndedIterator<Item=&T> + ExactSizeIterator + Clone.

@thenewwazoo
Copy link

thenewwazoo commented Sep 16, 2016

Raising this from the dead to say that this just bit me, as a relative newbie to Rust (e.g. "why do I have to dereference twice in .filter?)

@steveklabnik steveklabnik added T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. and removed T-tools labels May 18, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 22, 2017
@QuietMisdreavus
Copy link
Member

I've started #45039 to work on this.

bors added a commit that referenced this issue Nov 21, 2017
…z,QuietMisdreavus

show in docs whether the return type of a function impls Iterator/Read/Write

Closes #25928

This PR makes it so that when rustdoc documents a function, it checks the return type to see whether it implements a handful of specific traits. If so, it will print the impl and any associated types. Rather than doing this via a whitelist within rustdoc, i chose to do this by a new `#[doc]` attribute parameter, so things like `Future` could tap into this if desired.

### Known shortcomings

~~The printing of impls currently uses the `where` class over the whole thing to shrink the font size relative to the function definition itself. Naturally, when the impl has a where clause of its own, it gets shrunken even further:~~ (This is no longer a problem because the design changed and rendered this concern moot.)

The lookup currently just looks at the top-level type, not looking inside things like Result or Option, which renders the spotlights on Read/Write a little less useful:

<details><summary>`File::{open, create}` don't have spotlight info (pic of old design)</summary>

![image](https://user-images.githubusercontent.com/5217170/31209495-e59d027e-a950-11e7-9998-ceefceb71c07.png)

</details>

All three of the initially spotlighted traits are generically implemented on `&mut` references. Rustdoc currently treats a `&mut T` reference-to-a-generic as an impl on the reference primitive itself. `&mut Self` counts as a generic in the eyes of rustdoc. All this combines to create this lovely scene on `Iterator::by_ref`:

<details><summary>`Iterator::by_ref` spotlights Iterator, Read, and Write (pic of old design)</summary>

![image](https://user-images.githubusercontent.com/5217170/31209554-50b271ca-a951-11e7-928b-4f83416c8681.png)

</details>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants