A tuple of this Promise's value. Either (T) or an empty tuple.
Work-around for DMD bug 21804: https://issues.dlang.org/show_bug.cgi?id=21804
If your then callback argument is a tuple, insert this call before the then call. (Needs to be done only once per Promise!T instance.)
Registers a rejection handler. Equivalent to then(null, onRejected). Similar to the catch method in JavaScript promises.
Registers a finalization handler, which is called when the promise is resolved (either fulfilled or rejected). Roughly equivalent to then(value => onResolved(), error => onResolved()). Similar to the finally method in JavaScript promises.
Fulfill this promise, with the given value (if applicable).
Ignore this promise leaking in debug builds.
Reject this promise, with the given exception.
Registers the specified fulfillment and rejection handlers. If the promise is already resolved, they are called as soon as possible (but not immediately).
Special overload of then with no onFulfilled function. In this scenario, onRejected can act as a filter, converting errors into values for the next promise in the chain.
A promise for a value T or error E.
Attempts to implement the Promises/A+ spec (https://promisesaplus.com/), with the following deviations:
- Sections 2.2.1.1-2, 2.2.7.3-4: Due to D strong typing, the only applicable interpretation of "not a function" is null.
- Section 2.2.5: JavaScript-specific, and does not apply to D.
- Section 2.2.7.2: In D, thrown objects may only be descendants of Throwable. By default, Exception objects are caught, and passed to onRejected handlers.
- Section 2.2.7.1/3: In the case when onFulfilled is null but onRejected is not, the returned promise may be resolved with either the fulfilled value of the current promise or the return value of onRejected. In this case, the type of the returned promise value is the D common type of the two, or void if none.
- Section 2.3.1: Instead of rejecting the promise with a TypeError, an assertion failure is thrown.
- Section 2.3.3: Not implemented. This section facilitates interoperability with other implementations of JavaScript promises, though it could be implemented in D using DbI to support arbitrary then-able objects.
Additionally, this implementation differs from typical JavaScript implementations as follows:
- T may be void. In this case, fulfill, and the delegate in first argument of then, take zero arguments instead of one.
- Instead of the constructor accepting a function which accepts the fulfill / reject functions, these functions are available as regular methods.
- Attempts to fulfill or reject a non-pending promise cause an assertion failure instead of being silently ignored. (The Promises/A+ standard touches on this in section 2.3.3.3.3.)
- catch is called except (because the former is a reserved D keyword).
- finally is called finish (because the former is a reserved D keyword).
- In debug builds, resolved Promise instances check on destruction that their value / error was passed on to a handler (unless they have been successfully fulfilled to a void value). Such leaks are reported to the standard error stream.