No entiendo el propósito del código. Al parecer anda pero imagino que por validar vos te referías a otra cosa?

Si la idea es reimplementar Promise, se me ocurre que va más por este lado (esta implementación es incompleta porque no maneja los errores que creo Promise hace con catch. Tampoco soporta encadenamientos de then. Pero puede servir como una primera versión para implementar el resto:

type Callback<T> = (t: T) => void;
type Resolver<T> = (t: T) => void;
type Rejecter = (any) => void;
type ConstructorFunction<T> = (r: Resolver<T>, rr: Rejecter) => void;

class Future<T> {
  private callbacks: Callback<T>[] = [];
  private solved = false;
  private result: T;

  constructor(cf: ConstructorFunction<T>) {
    cf(this.solve, this.reject);
  }

  solve(t: T) {
    this.result = t;
    for (let c of this.callbacks) {
      c(t);
    }
  }

  reject(_reason: any) {
    // call
  }

  then(callback) {
    if (this.solved) {
      callback(this.result);
    } else {
      this.callbacks.push(callback);
    }
  }
}

new Promise<number>((resolve, reject) => {
  resolve(1);
  reject("foo");
});

new Future<number>((resolve, reject) => {
  resolve(1);
  reject("bar");
});

FAaaaa muy interesante lo que me dejas de código @fernandezpablo85 . No era mi intención reemplazar a las Promises... aunque me gusta la propuesta que haces con Futures (como se nota que estuviste en Scala jajaja, pues sospecho que el sinonimo Promesa = Future viene de ese lenguaje...).

Mi intención era saber si estaba bien la reimplementación de defer. El tema con las promesas nativas es que tenés que poner todo dentro de la función que pasas como argumento al Promise.New te puede complicar o hacer dificil combinarlo con otras porciones de código.

Sea como sea... te zarpaste! gracias amigo!!!