# Revisiting spotlight / "notable traits" in rustdoc

**URL:** <https://internals.rust-lang.org/t/revisiting-spotlight-notable-traits-in-rustdoc/14759>\
**Category:** tools and infrastructure\
**Created:** [May 23, 2021, 1:08am UTC](https://internals.rust-lang.org/t/revisiting-spotlight-notable-traits-in-rustdoc/14759 "2021-05-23T01:08:22Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![jsha](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jsha/32/7891_2.png) [@jsha](https://internals.rust-lang.org/u/jsha)\
**Post date:** [May 23, 2021, 1:08am UTC](https://internals.rust-lang.org/t/revisiting-spotlight-notable-traits-in-rustdoc/14759/1 "2021-05-23T01:08:22Z")

</div>

Rustdoc has a "notable traits" tooltip when hovering the (i) icon next to some return values. It currently looks like this:

 ![iter notable](https://us1.discourse-cdn.com/flex002/uploads/rustlang/original/2X/4/4b6cc9e4ad60e2cad7aa20619341a9e6063a338d.png)

[It was implemented in 2017](https://github.com/rust-lang/rust/pull/45039), in response to a [2015 issue requesting more clarity about iterator returns](https://github.com/rust-lang/rust/issues/25928). @GuillaumeGomez[removed it in early 2020](https://github.com/rust-lang/rust/pull/69514) for being too complex and not doing its job. @Manishearth [re-added it in mid-2020](https://github.com/rust-lang/rust/pull/74370) after a [useful forum thread here](https://internals.rust-lang.org/t/feedback-on-important-traits-rustdoc-feature/12752).

The current implementation still doesn't do its job because the (i) is so unobtrusive. Most people don't notice it, as @GuillaumeGomez' Twitter poll suggested. Also, even if you notice the (i), the text in the box is inscrutable to a beginner (and still hard to eyeball for an experienced Rustacean).

The current version considers Iterator, Read, Write, and Future to be notable. Note that the original issue requested a way to show the iteration type of a returned iterator - it didn't request a generic way to show notable traits. And most of the discussion in @Manishearth's forum thread centered around iterators. I haven't seen someone make the case for Read, Write, and Future definitely needing this treatment.

I think we can do a lot better by specializing to just Iterator, and displaying some text inline rather than hiding it behind a tooltip:

 ![image](https://us1.discourse-cdn.com/flex002/uploads/rustlang/original/2X/e/e6abb722f442670cb1def50c22c464729baa91de.png)

Thoughts?

---

<div class="post-metadata">

**Author:** ![steffahn](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/steffahn/32/13288_2.png) [@steffahn](https://internals.rust-lang.org/u/steffahn)\
**Post date:** [May 23, 2021, 7:08am UTC](https://internals.rust-lang.org/t/revisiting-spotlight-notable-traits-in-rustdoc/14759/2 "2021-05-23T07:08:17Z")

</div>

I think it's very reasonable to also consider `Future`. This makes reading the docs for e. g. traits like [`AsyncReadExt`](https://docs.rs/futures/0.3.15/futures/io/trait.AsyncReadExt.html) _a lot_ easier.

---

<div class="post-metadata">

**Author:** ![scottmcm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/scottmcm/32/2355_2.png) [@scottmcm](https://internals.rust-lang.org/u/scottmcm)\
**Post date:** [May 23, 2021, 8:00am UTC](https://internals.rust-lang.org/t/revisiting-spotlight-notable-traits-in-rustdoc/14759/3 "2021-05-23T08:00:03Z")

</div>

Spitballing: This is a bit of an abuse of notation, but maybe

```rust
-> IterMut<'_, K, V, Item = (&K, &mut V)>
-> Read<'a, Self, Output = Result<usize, Error>>

```

Alternatively, [Pre-RFC: Absolute minimum for in-impl imports](https://internals.rust-lang.org/t/pre-rfc-absolute-minimum-for-in-impl-imports/14753) has me pondering [inherent trait impls](https://github.com/rust-lang/rfcs/pull/2375) as a potential definition for "notable", though of course that wouldn't be helpful to anyone for a while.

---

<div class="post-metadata">

**Author:** ![SkiFire13](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/skifire13/32/7579_2.png) [@SkiFire13](https://internals.rust-lang.org/u/SkiFire13)\
**Post date:** [May 23, 2021, 9:10am UTC](https://internals.rust-lang.org/t/revisiting-spotlight-notable-traits-in-rustdoc/14759/4 "2021-05-23T09:10:01Z")

</div>

> [@jsha](#):
>
> ![image](https://us1.discourse-cdn.com/flex002/uploads/rustlang/original/2X/e/e6abb722f442670cb1def50c22c464729baa91de.png)

This looks nice, but I would change the works. Instead of "an Iterator of &T", which doesn't work for all types, I would use something like "`impl Iterator<Item = &'a T>`", possibly using the same `'a` and `T` as the `impl` block/fn generics that are used.

For example if we had:

```rust
impl<'a, T> Iterator for Iter<'a, T> {
    type Item = &'a T;
    // ...
}

impl<U> [U] {
    pub fn iter(&self) -> Iter<'_, U> { /* ... */ }
}

```

Then in the docs, on the right of the function signature, there would be written "`impl Iterator<Item = &'_ U>`".

Possible downsides:

- This may create confusion with lifetimes, in particular elided lifetimes
- If the type of `Item` (or other types present in the trait implementation) are pretty long this could easily get out of control.
- How do you show multiple notable traits? Think for example of types that implement both `Read` and `BufRead`, or `Iterator` and `FusedIterator`

It would also be nice to have a way to restrict/select notable traits. For example in the docs of `Iterator::by_ref` I don't care that the returned reference may implement `Read`, I only care about `Iterator`.

---

<div class="post-metadata">

**Author:** ![CAD97](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cad97/32/3460_2.png) [@CAD97](https://internals.rust-lang.org/u/CAD97)\
**Post date:** [May 23, 2021, 10:59am UTC](https://internals.rust-lang.org/t/revisiting-spotlight-notable-traits-in-rustdoc/14759/5 "2021-05-23T10:59:52Z")

</div>

The point of the OP suggestion is that (i) is trying to serve the general case, and failing at even just (effectively) serving the basic case of just `Iterator`. So perhaps we would be better off with a specific case for `Iterator` rather than trying to have a general system that serves all cases.

At a minimum, we definitely can tone down the notable traits from "it could implement it if the input type does" because that's not super useful. Instead, restrict it to the one that's guaranteed to hold.

I do think this is similar to inherent trait impls, but distinct. The whole point of the notable traits feature is that some types exist primarily to be used through the trait -- so the marker should live on the impl, not the trait!

Instead of `#[doc(spotlight)] trait Iterator`, give us just `#[doc(spotlight)] impl Iterator for Iter`.

The standard argument against this is that ~most implementors of the notable trait would want to spotlight it. I think this hasn't really held up in practice: we both over spotlight every potential notable trait in generic situations and under spotlight in that it's hidden in the (i).

By putting the annotation on the impl, you gain the communication of RPIT with the control of a named type. And I think treating it similarly to RPIT in the docs is the ideal case.

The reasoning for sticking the spotlight behind the (i) is that it claims to much space otherwise. Making it granularly opt in puts more effort on the library author for documenting well, but because it's an active decision to spotlight it, it also allows us to spend more space on it, because we've been told it's important.

I don't have any useful input design wise, but content wise, I think this is the best way of thinking about it.

---

<div class="post-metadata">

**Author:** ![GuillaumeGomez](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/guillaumegomez/32/2510_2.png) [@GuillaumeGomez](https://internals.rust-lang.org/u/GuillaumeGomez)\
**Post date:** [May 23, 2021, 11:00am UTC](https://internals.rust-lang.org/t/revisiting-spotlight-notable-traits-in-rustdoc/14759/6 "2021-05-23T11:00:39Z")

</div>

I think simplifying it is a good idea. As long as we keep a link on the various types in the spotlight display, all good for me!

---

<div class="post-metadata">

**Author:** ![jsha](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jsha/32/7891_2.png) [@jsha](https://internals.rust-lang.org/u/jsha)\
**Post date:** [May 23, 2021, 4:34pm UTC](https://internals.rust-lang.org/t/revisiting-spotlight-notable-traits-in-rustdoc/14759/7 "2021-05-23T16:34:29Z")

</div>

> [@CAD97](#):
>
> The point of the OP suggestion is that (i) is trying to serve the general case, and failing at even just (effectively) serving the basic case of just `Iterator` . So perhaps we would be better off with a specific case for `Iterator` rather than trying to have a general system that serves all cases.

Exactly. Great summary, thanks.

> [@CAD97](#):
>
> By putting the annotation on the impl, you gain the communication of RPIT with the control of a named type. And I think treating it similarly to RPIT in the docs is the ideal case.

I had to search for RPIT in the source, so for anyone reading who needs the acronym expanded: Return Position Impl Trait.

> [@steffahn](#):
>
> I think it's very reasonable to also consider `Future` . This makes reading the docs for e. g. traits like [`AsyncReadExt`](https://docs.rs/futures/0.3.15/futures/io/trait.AsyncReadExt.html) _a lot_ easier.

Good point. The main reasons I want to specialize to Iterator are (a) we don't have to deal with spotlighting multiple traits, and (b) there's a single, well-known output type. Since it's quite unusual for a type to implement both `Iterator` and `Future`, we could say "if both of these, one of them wins."

Current:

 ![async-read](https://us1.discourse-cdn.com/flex002/uploads/rustlang/original/2X/5/51974b7bbaee3219b207e6c49e56fdd33a7b8d55.png)

Possible future:

 ![image](https://us1.discourse-cdn.com/flex002/uploads/rustlang/original/2X/2/257769d126f0cc0de9b175513d2c3c773c9c161d.png)

---

<div class="post-metadata">

**Author:** ![matklad](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/matklad/32/12266_2.png) [@matklad](https://internals.rust-lang.org/u/matklad)\
**Post date:** [May 23, 2021, 4:52pm UTC](https://internals.rust-lang.org/t/revisiting-spotlight-notable-traits-in-rustdoc/14759/8 "2021-05-23T16:52:59Z")

</div>

Somewhat related, in rust-analyzer, we already have some logic to "erase" some concrete iterator types to an `impl Trait` syntax.

 ![image](https://us1.discourse-cdn.com/flex002/uploads/rustlang/original/2X/6/62cd40d2449153e14db3270c2682436e7b090d58.png)

We use a rather ham-handed approach to deciding whether we should do the erasure:

> <https://github.com/matklad/rust-analyzer/blob/7283163bb9b4314ec3c7b25fad90ae794e7b7320/crates/ide/src/inlay_hints.rs#L229-L231>

---

<div class="post-metadata">

**Author:** ![Manishearth](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/manishearth/32/50_2.png) [@Manishearth](https://internals.rust-lang.org/u/Manishearth)\
**Post date:** [May 23, 2021, 5:18pm UTC](https://internals.rust-lang.org/t/revisiting-spotlight-notable-traits-in-rustdoc/14759/9 "2021-05-23T17:18:56Z")

</div>

I disagree that _just_ specializing to Iterator is a good idea. The full impls are really really useful because the _precise_ types involved often become important, as well as the trait bounds.

I do think the proposed UI is nice and useful but I don't think it should _replace_ the info tooltip, I think it should supplement it: in cases where there is a straightforward answer, we should show the straightforward answer and stick the `(i)` inside the parentheses so it's clear they're linked.

My guess is that there will be cases where we can still show an `(i)` but there is no straightforward answer as to what to show in the grey text portion. Or cases where there is but we need to incrementally approach it: When things like associated types of type parameters get involved for example, implementation-wise collapsing it into a readable `Iterator of X` is going to be tricky.

I also do think the `Read`, `Write`, and `Future` impls are important, and it's worth highlighting that these three traits are used by subsets of the community. Most rust code uses iterators, but only a subset of rust code really cares about this, which is why these three being notable seems less useful. It is not necessary that a feature serve _everyone_, as long as it's not overly degrading the experience for those who don't need it.

(This logic is also why I'm against replacing this UI: I find the amount of information exposed by the existing UI incredibly useful, I need it on a regular basis, and just because it's not useful to _everyone_ doesn't mean it should be _removed_, but perhaps supplemented)

> The current implementation still doesn't do its job because the (i) is so unobtrusive. Most people don't notice it, as @GuillaumeGomez' Twitter poll suggested

I don't see any evidence for this? The twitter poll is for the older UI.

---

<div class="post-metadata">

**Author:** ![dhm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/dhm/32/4879_2.png) [@dhm](https://internals.rust-lang.org/u/dhm)\
**Post date:** [May 23, 2021, 9:13pm UTC](https://internals.rust-lang.org/t/revisiting-spotlight-notable-traits-in-rustdoc/14759/10 "2021-05-23T21:13:05Z")

</div>

While I like the idea, I'm not fond of it being non-Rust syntax intermingled with Rust one (I am referring to "an Iterator of ..."). Remember that CSS styling may not be available to all rustdoc users due to accessibility reasons, so one ought to avoid relying too much on that.

I personally think that the nicer syntax for this is to have rustdoc emit trivially true `where` clause bounds:

```rust
pub fn iter(&self) -> Iter<'_, T>
where
                      Iter<'_, T> : Iterator<Item = &'_ T>,
                      Iter<'_, T> : Read, // let's imagine multiple highlighted traits
    /* original where clauses, if any */

```

Or, if we really wanted to stretch things, a shorthand syntax like:

```rust
pub fn iter(&self) -> Iter<'_, T> : Iterator<Item = &'_ T>
                                  + Read

```

(although the latter doesn't generalize as well for bounds "iterable"-like,   
such as `&'_ ReturnType : IntoIterator<...>`, but maybe that's not an issue 🤔 )

* * *

In that regard, I don't like `impl Iterator` syntax if the original code did not have it, since the actual type, whether we like it or not, is meaningful, Rust-wise (_e.g._, replacing it with an `impl Iterator` is a breaking change), so if rustdoc made that replacement it would technically be lying.

* * *

Finally, only tangentially related, I find that signatures involving elided lifetimes can already be hard enough to "unelide"; and if trait bounds are to be added, then rustdoc ought to seriously consider adding a (potentially opt-in) mechanism to unelide lifetimes (which, incidentally, could help teaching Rust and making complex signatures more readable).

---

<div class="post-metadata">

**Author:** ![Lonami](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/lonami/32/6774_2.png) [@Lonami](https://internals.rust-lang.org/u/Lonami)\
**Post date:** [May 23, 2021, 9:16pm UTC](https://internals.rust-lang.org/t/revisiting-spotlight-notable-traits-in-rustdoc/14759/11 "2021-05-23T21:16:24Z")

</div>

Would a special section dedicated to listing the notable traits of the return value be too intrusive? In my opinion, it would be too much to put it in the same line as the fn definition.

Maybe it could be a `<details>` expandable tag with a `<summary>` of "Notable traits implemented by the return type". That should definitely be more easily noticed.

---

<div class="post-metadata">

**Author:** ![Manishearth](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/manishearth/32/50_2.png) [@Manishearth](https://internals.rust-lang.org/u/Manishearth)\
**Post date:** [May 24, 2021, 1:11am UTC](https://internals.rust-lang.org/t/revisiting-spotlight-notable-traits-in-rustdoc/14759/12 "2021-05-24T01:11:08Z")

</div>

> [@dhm](#):
>
> While I like the idea, I'm not fond of it being non-Rust syntax intermingled with Rust one (I am referring to "an Iterator of ..."). Remember that CSS styling may not be available to all rustdoc users due to accessibility reasons, so one ought to avoid relying too much on that.

I actually think using Rust syntax here is fraught because it might be confused with actual Rust syntax. For example, those `where` bounds aren't actually real, and that seems pretty confusing. Similarly `Iter: Iterator` will give people the impression that such syntax _works_.

If you're worried about accessibility and CSS; HTML is semantic and these needs can be easily addressed by using the appropriate tags or ARIA categories.

---

<div class="post-metadata">

**Author:** ![Aloso](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/aloso/32/5039_2.png) [@Aloso](https://internals.rust-lang.org/u/Aloso)\
**Post date:** [May 24, 2021, 1:16am UTC](https://internals.rust-lang.org/t/revisiting-spotlight-notable-traits-in-rustdoc/14759/13 "2021-05-24T01:16:44Z")

</div>

> [@dhm](#):
>
> Remember that CSS styling may not be available to all rustdoc users due to accessibility reasons

Not an expert, but I think adding the proper `aria` attributes to the element would help.

I think expressing the notable traits in a way that looks like Rust syntax would be confusing, because people might assume that they are part of the original code, and that the notable traits are trait bounds that the caller of the function must satisfy. Other people might get stumped why rustdoc only adds some traits and not others.

If the notable traits are instead written in prose (_"an iterator of ..."_), I think it's clear enough that this is not Rust syntax, and it can be made more obvious by using a smaller, proportional font. I don't think there's any reason why the documentation must be valid Rust syntax.

---

<div class="post-metadata">

**Author:** ![skysch](https://avatars.discourse-cdn.com/v4/letter/s/f05b48/32.png) [@skysch](https://internals.rust-lang.org/u/skysch)\
**Post date:** [May 24, 2021, 3:20am UTC](https://internals.rust-lang.org/t/revisiting-spotlight-notable-traits-in-rustdoc/14759/14 "2021-05-24T03:20:26Z")

</div>

> [@Aloso](#):
>
> I don't think there's any reason why the documentation must be valid Rust syntax.

Because people will copy & paste it into their code. _Especially_ if it is some complicated function signature you have to implement for a trait.

---

<div class="post-metadata">

**Author:** ![jsha](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jsha/32/7891_2.png) [@jsha](https://internals.rust-lang.org/u/jsha)\
**Post date:** [May 24, 2021, 4:52am UTC](https://internals.rust-lang.org/t/revisiting-spotlight-notable-traits-in-rustdoc/14759/15 "2021-05-24T04:52:34Z")

</div>

> [@Manishearth](#):
>
> > [@jsha](#):
> >
> > The current implementation still doesn't do its job because the (i) is so unobtrusive. Most people don't notice it, as @GuillaumeGomez' Twitter poll suggested
> 
> I don't see any evidence for this? The twitter poll is for the older UI.

I stand corrected, thanks for pointing this out. So I fall back for evidence on my personal experience: I did not notice the (i) until its embedded `<div>` showed up in a `tidy` run. And also on a general feeling that if the information is very important we should dedicate some space to showing it by default; and if not we should rely on clicking through (and ensuring that the clicked-to page loads very fast, and the link takes you directly to the most important aspect of the target).

> [@Manishearth](#):
>
> I also do think the `Read` , `Write` , and `Future` impls are important, and it's worth highlighting that these three traits are used by subsets of the community.

Good points. I see why `Future` needs the same treatment. Can you tell me more about the subsets of the community that need spotlight treatment for `Read` and `Write`? Are there cases where a return type implements multiple of these four traits, and they all need to be spotlighted?

> [@skysch](#):
>
> people will copy & paste it into their code. _Especially_ if it is some complicated function signature you have to implement for a trait.

To solve this, we can make that part of the function signature not participate in selection: [user-select - CSS: Cascading Style Sheets | MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/user-select#syntax).

---

<div class="post-metadata">

**Author:** ![Manishearth](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/manishearth/32/50_2.png) [@Manishearth](https://internals.rust-lang.org/u/Manishearth)\
**Post date:** [May 24, 2021, 5:40am UTC](https://internals.rust-lang.org/t/revisiting-spotlight-notable-traits-in-rustdoc/14759/16 "2021-05-24T05:40:39Z")

</div>

> [@jsha](#):
>
> And also on a general feeling that if the information is very important we should dedicate some space to showing it by default; and if not we should rely on clicking through (and ensuring that the clicked-to page loads very fast, and the link takes you directly to the most important aspect of the target).

Is it "very important"? It's very useful for people working with complex types, but ... that's not everyone! And that's okay!

Clicking through is not a solution _at all_, often you need to get this information in a flash for multiple methods and having to context switch a bunch makes it harder to retain it. Especially since clicking through gives you a lot more information and you need to pinpoint the stuff you need.

I do think that showing some cases by default makes sense, but I'm very much against the "either show it by default or not at all" dichotomy.

> [@jsha](#):
>
> Good points. I see why `Future` needs the same treatment. Can you tell me more about the subsets of the community that need spotlight treatment for `Read` and `Write` ? Are there cases where a return type implements multiple of these four traits, and they all need to be spotlighted?

Mostly when you're doing IO stuff.

> [@jsha](#):
>
> So I fall back for evidence on my personal experience: I did not notice the (i) until its embedded `<div>` showed up in a `tidy` run

I think the (i) being unobtrusive is _fine_; this is more of a power user feature, not everything needs to be immediately obvious to users. I don't mind making it more noticeable or by showing "(an iterator of T)" in some cases. But again, I don't think that's justification for _replacing_ the feature unless the new feature can satisfy the same use cases.

* * *

So one concern I have is that (i) right now shows a lot of stuff and it's not always obvious (programmatically) which is the most important entry there. I think that all the entries are _important_ to show, but one of them is the most obvious and that's what would feed into the show-by-default UI being proposed here.

Perhaps we can have an attribute for _methods_ to opt in to this behavior, which can identify the "most important" trait. The downside is that non-stdlib crates do not get this for free, like they do for (i) right now.

---

<div class="post-metadata">

**Author:** ![Manishearth](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/manishearth/32/50_2.png) [@Manishearth](https://internals.rust-lang.org/u/Manishearth)\
**Post date:** [May 24, 2021, 5:51am UTC](https://internals.rust-lang.org/t/revisiting-spotlight-notable-traits-in-rustdoc/14759/17 "2021-05-24T05:51:53Z")

</div>

Fundamentally, I think there might be two sets of use cases involved here: the simpler case where you're just calling a function and want to know what you _should_ do with the thing you got back ("iterate it" / "await it" / "read it" / etc), and the more complicated case where all of your types are abstract and you need to be able to reason about the exact type you're getting back (which is where knowing the full `impl` bounds / `where` clauses comes up).

The latter is the one that comes up more often for me and for other folks who write code heavy with type parameters, but a lot of people in this thread seem to be focused on the former. The former is important too, but I basically want to be really clear that the feature not effectively solving the former use case does not mean that it isn't effectively solving _a_ use case.

---

<div class="post-metadata">

**Author:** ![jsha](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jsha/32/7891_2.png) [@jsha](https://internals.rust-lang.org/u/jsha)\
**Post date:** [May 24, 2021, 4:49pm UTC](https://internals.rust-lang.org/t/revisiting-spotlight-notable-traits-in-rustdoc/14759/18 "2021-05-24T16:49:35Z")

</div>

Can you link to some crates or types that you're talking about so I can better understand the use case? And when you say "reason about the exact type you're getting back," what are some examples of the types of reasoning you're doing?

---

<div class="post-metadata">

**Author:** ![Manishearth](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/manishearth/32/50_2.png) [@Manishearth](https://internals.rust-lang.org/u/Manishearth)\
**Post date:** [May 24, 2021, 5:02pm UTC](https://internals.rust-lang.org/t/revisiting-spotlight-notable-traits-in-rustdoc/14759/19 "2021-05-24T17:02:05Z")

</div>

I haven't written such code in a while so I'm afraid I can't think of crates immediately.

The types of reasoning are basically around "what is the final value of the `Item` associated type after being chained through a lot of iterators" for example.

---

<div class="post-metadata">

**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\
**Post date:** [August 22, 2021, 5:02pm UTC](https://internals.rust-lang.org/t/revisiting-spotlight-notable-traits-in-rustdoc/14759/20 "2021-08-22T17:02:33Z")

</div>

Closed on August 22, 2021, 5:02pm UTC

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.