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