nim-chronos
nim-chronos copied to clipboard
status-im
add shortcuts to create completed futures
there's a few places in nbc where we create completed or failed futures, and this is a convenient way to do it - it's similar to how you create a Result[A,B].ok(value) - instead of first creating an unfinished future, you can use these constructors with let and other features that make code less risky - ie if a: Future[T].complete(x) else: Future[T].fail(b) for example.
Yes, to a certain extent, it's subjective, but it's aimed at using the safety features of the language better. completed is taken already, to check if the future is complete. parameter overloading like this should be safe, everything is in the same module so we shouldn't have sandwitch problems. Result looks like this all the way and doesn't have issues.
The test updates on the other hand are a consequence of unittest2 already putting each test in a separate proc - no need to do it manually any more which makes the tests slightly easier to understand: the checks can now give more detailed errors instead of values like "300" that don't mean anything.
Manual Future[T] management is unsafe by design.
All this Future[T].addCallback() and closure procedures do not make code simpler. Right now chronos allows both paradigms to be combined (callback soup and async/await), but at the end i wish to prohibit usage of callback soup. So i can consider this API as unsafe and should only be used inside of chronos. All other consumers should avoid this primitives and use async/await instead.
Manual Future[T] management is unsafe by design.
maybe, but it's needed to extend chronos itself sometimes to more precisely control execution (locks, special queues, etc) - these functions are rarely used for adding callbacks, but rather for beginning execution chains that async functions consume. Exactly because these use cases are advanced and more difficult to write, it's better to have as safe tools as possible to do it, and constructors like these help safety in generrral.
In a few exceptional places, they're also needed to work around inefficiencies in Nim itself, in particular the version we're using today - ie constructing a closure environment is quite expensive in some cases, as is waiting for an entire poll loop.
Sorry but i'm still not completely convinced that such primitives are needed. Tests refactoring could be merged.