Should we provide an ordered=True option?

[njsmith]

Right now, the incremental result reporting always reports results as they're ready, so the order of the output doesn't necessarily match the order of the input. (Except for run_all, since it's not incremental anyway.)

Should we provide an option ordered=True to request that the output order must match the input order?

If we do then there's some subtle interaction with backpressure: if task 0 is slow, we probably don't want to buffer up results from tasks 1...10000 while waiting for task 0 to finish. I think the way to avoid this is to do the reordering directly inside the workers, rather than with a separate buffering/reordering task. When ordered=True, have each worker wait for the previous work to report its result before this worker reports its result. And worker tasks still count against the metered limits until after they report their result.

[jtrakk]

I can imagine users accidentally relying on an ordering assumption and getting wrong results. Having unordered_run_on_each() be a separate function might be safer.

[oremanj]

I think Trio's nondeterministic scheduling will foil most order-preservation assumptions pretty quickly, so I'm not worried about issues with the default being ordered.

I think ordered=True would be useful to support, specifically because it's the sort of thing that's hard for someone else to implement on top of trimeter (since the ideal implementation would be within the worker).