should_implement_trait triggers for next() where the return value has lifetimes

[taralx]

This should not trigger the lint until we get generic associated types:

pub fn next(&mut self) -> Option<(&K, &mut V)>

[felix91gr]

@taralx we have GATs now, but I'm not exactly sure if this issue has been solved or not.

I want to test it. Could I ask you to give me more context? A simple snippet of code that should trigger the lint would suffice :3

[taralx]

From 5 years ago? Not sure. That looks like an Iterator impl, try it?

[felix91gr]

I have no clue. If the original context is lost, then perhaps this issue can be closed?

[y21]

I think it's still relevant. To expand on the description, here's a concrete repro that triggers the lint:

pub struct S<T>(T);

impl<T> S<T> {
    pub fn next(&mut self) -> Option<&mut T> {
        Some(&mut self.0)
    }
}

That can't be Iterator::next because the &mut T borrows from &mut self. That lifetime relationship isn't expressible with the Iterator trait afaik. GATs technically would solve this for a new LendingIterator trait, but it won't help with the real Iterator trait

[y21]

... actually reading the lint description/diagnostic, this might also just be working as intended, as it seems to also suggest renaming the method to something else other than next if implementing it doesn't work, which I guess isn't unreasonable.

= help: consider implementing the trait std::iter::Iterator or choosing a less ambiguous method name