new rule - re-iteration of generator that's already been iterated over

[DetachHead]

to my knowledge no existing linter or type checker is able to detect mistakes like this. for example:

def get_values() -> list[int]:
    return [i for i in range(3)]

values = get_values()

assert 4 not in values # passes
assert 1 in values # passes

but if get_values is updated to return a Generator instead of a list, it can unintentionally break existing usages:

from typing import Generator

def get_values() -> Generator[int]:
    return (i for i in range(3))

values = get_values()

assert 4 not in values # passes
assert 1 in values # fails because the generator has no more values to iterate

i've encountered issues like this several times, so it would be nice if ty had a rule for it.

[dangotbanned]

Not sure if it would still be as helpful, but I think an easier thing to flag on that example would be using __contains__ on an Iterator?

I personally haven't ever written code that intended to consume an iterable with a containment check

[DetachHead]

I personally haven't ever written code that intended to consume an iterable with a containment check

me neither, but in my experience this often happens unintentionally when updating a function that returns a list to return a Generator, where there are existing usages that assume it's a list

[sharkdp]

Thank you for opening this, sounds like useful rule indeed.

I'm not sure how that would be implemented in ty today. Reminds me of affine types ("move semantics").

[AlexWaygood]

Yes, this does sound useful, but hard to implement. We'd have to track operations that could potentially exhaust a generator/iterator.