{"body":"# Theory:                   \r\n# Futures have some properties that are useful for manual memory management.\r\n# Namely, after the \"lastReadOf(future<x>)\", it is guaranteed safe to free any\r\n# memory associated with future<x>.\r\n# This includes any closure environments the reference future<x>.\r\n# In fact, any closure environments that reference future<x> **must** be freed along with\r\n# future<x> in order to prevent dangling pointers / GC collection errors (these are equivalent.)\r\n# Questions:                   \r\n# - should this be a subclass or a variant type?\r\n# - is a proc(){.closure.} equivalent to a ref proc(){.closure.} (good enough at least?)                     \r\n# - The async macro produces 1 closure + 1 closure iterator. But for the general case,                  \r\n#   do we need a seq[proc(){.closure.}]?        \r\n#   For example, recvFromInto, and sendTo from asyncdispatch.nim, generate Futures\r\n#   \"manually\", outside of the async macro. They have a single closure (for the socket),  \r\n#   and no closure iterator....                        \r\n  DisposableFuture*[T] = ref object of Future[T]   \r\n    closureRef: proc(){.closure.}\r\n    closureIterRef: iterator(): FutureBase {.closure.}\r\n  FutureError* = object of Exception\r\n    cause*: FutureBase","name":"","extension":"txt","url":"https://www.irccloud.com/pastebin/13Q28ZQO","modified":1572981750,"id":"13Q28ZQO","size":1268,"lines":20,"own_paste":false,"theme":"","date":1572981750}