v1.3.0

• When you passed multiple values to yieldAsync, it used to construct a tuple and yield that tuple. This behavior has been deprecated. Please parenthize your values yourself.

It was a bad idea from the start. Regular yield statement in Nim does not accept multiple values—why should we? A DSL should mimic the syntax and semantics as close as possible. Being more permissive is still a deviation from the original, which increases cognitive load.

To clarify: yieldAsync itself is not deprecated; only its many-argument overload is.

v1.2.5

• Selective imports (from asyncIters import ...) should now work. See #1 for more information.

v1.2.4

Fixed compilation errors issued when --experimental=strictFuncs was passed.

v1.2.3

If you pass -d=asyncBackend:chronos and compile with a modern version of Chronos, import asyncIters brings chronos/futures in scope. This is on par with forwarding std/asyncfutures with default backend.

v1.2.2

• yieldAsync and yieldAsyncFrom are not magic identifiers anymore. You can invoke them wherever you wish.
• Silenced several compiler hints. Should build quietly now under any configuration.

v1.2.1

• A template defined inside an asyncIter or an awaitIter loop body is allowed to use relevant control structures: yieldAsync, yieldAsyncFrom; break, continue, return, result.

v1.2.0

• Chronos is officially supported. With minor restrictions; see the readme.
• All async iterators and awaitIter loop bodies are required to be GC-safe (i.e., to not touch global variables holding GC-allocated data).
• Accessing the result implicit variable in loops does not incur performance penalties anymore.

v1.1.0

• Instead of CustomAsyncIterator[T, Future[uint32]], use customAsyncIterator(T, Future) now. This template produces the same type but does not expose the fact that it relies on uint32.
• Added preliminary support for chronos (not functional yet).
• Fixed a compilation error triggered, for example, when an async iterator was declared inside a template.

v1.0.0

Release version 1.0.0