-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Comments
I'm generally not a fan, as text is hard to track with changes. I'd rather see |
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. |
Ideally all these interfaces should just say On Sun, May 31, 2015 at 11:33 AM, bluss notifications@github.com wrote:
|
Yes but that's far future right now. I'm wondering what we are going to do about multiple traits. I mean, |
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 |
I've started #45039 to work on this. |
…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>
The docs for Vec::iter show the following type:
As a result, I was puzzled that the following doesn't work:
It turns out that that
Iter
implements an iterator with element type &T. On the Iter docs page we seetype 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:This is the approach taken in itertools docs (example) and I think it helps significantly.
The text was updated successfully, but these errors were encountered: