The future package define the semantics of asynchronous (future value) data access. The API can be used as either generic or type-safe manner: the utility of the former case is limited to wrapping a well-known channel/timer select pattern in a standard, tested, and modularized manner; and the latter obviates the need for casts but they do remain runtime mechanisms due to lack of support for generics. The package may provide type-safe variants for builtin types. Users can (and are free) to write their own variants for custom types, if that is a requirement. A reference implementation supporting untyped futures is provided, and can be used via exported future.NewUntypedFuture. API design was strongly inspired by Java's Futures. - Spec-Lite and Usage: Futures are designed for asynchronous hand-off of a reference between 1 or 2 (typically 2) 'threads' of execution. Conceptually, it is nothing more than wrapping a standard pattern of using a channel (of size 1) to transfer a reference or a value. API is designed for minimal overhead and delegates any required type-safety to the programmer user. The hand-off semantics are defined by the 'Future', and 'Provider' interfaces, where it is expected that the instantiator of future objects is the entity that has exposed an API returning future.Future(s). The general pattern of use is as follows: The implementation of a function | interface-method returning future.Future will instantiate a type supporting the future.Future & future.Provider interfaces. For example: This function | interface-method has the role of the future.Provider. For example: The consumer of the function | interface-method returning future.Future objects can (a) fire-and-forgetall-but-error, (b) block until results are provided, or (c) wait for a specified time (for cases such as meeting SLAs): The behavior of future.Future is _only specified_ given the constraint that the receiving party adheres to the following: The Result interface reference obtained by the receiver per above is conceptually a 'union' between an 'error' or 'value' (both regardless typed as interface{}). This package makes no assumptions about the ownership and life-cycle of the references (whether error or value) handed off via the futures, or for that matter, the references to Future objects themselves. Typically, the life-cycle of all objects created are close to the event bounds of creating the Future and obtaining either an error or value result, but that is entirely up to the user of the package. The untyped implementation does not maintain any references to the objects it creates. Compliant implentations are required to release any rosources associated with a future.Future object on a successful future.Future#Get | future.Future#TryGet.