Allow specifying TReturn and TNext for AsyncIterableIterator and AsyncIterable

[bterlson]

Partially fixes #33932 by giving a way to provide a better type than any for TReturn. Implementation is simply adding and plumbing the TReturn and TNext parameters for both AsyncIterableIterator and AsyncIterable, and updating baselines.

[DanielRosenwasser]

@typescript-bot test this
@typescript-bot user test this
@typescript-bot run dt

[typescript-bot]

Heya @DanielRosenwasser, I've started to run the extended test suite on this PR at 3b69bf2. You can monitor the build here. It should now contribute to this PR's status checks.

[typescript-bot]

Heya @DanielRosenwasser, I've started to run the parallelized Definitely Typed test suite on this PR at 3b69bf2. You can monitor the build here. It should now contribute to this PR's status checks.

[typescript-bot]

Heya @DanielRosenwasser, I've started to run the parallelized community code test suite on this PR at 3b69bf2. You can monitor the build here. It should now contribute to this PR's status checks.

[typescript-bot]

The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master.

[bterlson]

@typescript-bot test this
@typescript-bot user test this
@typescript-bot run dt

[typescript-bot]

Heya @bterlson, I've started to run the parallelized Definitely Typed test suite on this PR at aa0f332. You can monitor the build here. It should now contribute to this PR's status checks.

[typescript-bot]

Heya @bterlson, I've started to run the parallelized community code test suite on this PR at aa0f332. You can monitor the build here. It should now contribute to this PR's status checks.

[typescript-bot]

Heya @bterlson, I've started to run the extended test suite on this PR at aa0f332. You can monitor the build here. It should now contribute to this PR's status checks.

[ExE-Boss]

What about Iterable and IterableIterator?

Also, do note that this was originally rejected in #30790 (comment) by @rbuckton.

[bterlson]

@ExE-Boss I would argue for similar treatment, but given @rbuckton's trepidation I think we should wait and see what he thinks. If adding Iterable and IterableIterator to this PR would help, I will do it!

[rbuckton]

At one point in #30790 I was using unknown instead of any. The problem with undefined as a default is that not every Iterator can be assumed to return undefined, and making the type anything other than any or unknown caused a significant number of breaks in assignability where people were rolling their own custom iterators.

We also had issues with the fact that we were conflating T in Iterator and Iterable to include both the yielded and the returned type, and the fact that Iterator<T> was originally typed with return?(value?: any):

I am considering my concerns about adding TReturn and TNext to Iterable. My main concern is that it would dramatically increase .d.ts file output if suddenly every inferred Iterable<number> in the output became Iterable<number, void, undefined> because we fill in the default types at the time of compilation.

[sandersn]

Unfortunately, we never finished reviewing this PR. It is pretty old now, so I'm going to close it to reduce the number of open PRs.