Proposal: Ability to force the REPL to wait on a promise via a custom method implementation

[dsherret]

It would be useful to provide the repl an expression that returns an object, which can tell the Deno REPL to wait for its completion.

Example:

> doSomethingAsync()
5
> console.log(_); // outputs 5 and not the promise

Real example with https://github.com/dsherret/dax:

> import $ from "https://deno.land/x/dax/mod.ts";
undefined
> $`git commit -m "Some message"`
On branch lazy_emit
Your branch is up to date with 'origin/lazy_emit'.

nothing to commit, working tree clean
> 

Object Author Implementation

Instead of resolving all promises this way, we could provide a custom method similar to Deno.customInspect, like so:

class MyCustomPromise implements PromiseLike<number> {
  // ...etc...

  async [Symbol.for("Deno.customReplPromise")](
    onfulfilled: ...etc...,
    onrejected: ...etc...,
  ): Promise<number> {
    // ...etc..
    return 5;
  }
}

If someone wanted to re-use their promise implementation they would just do:

class MyCustomPromise implements PromiseLike<number> {
  // ...etc...
  [Symbol.for("Deno.customReplPromise")](
    onfulfilled: ...etc...,
    onrejected: ...etc...,
  ): Promise<number> {
    return this.then(onfulfilled, onrejected);
  }
}

REPL Implementation

The repl would check if this method exists and if it does, it would call it then wait for its result.

Why?

1. It's less to write. In the REPL it's nice to be lazy.
2. The command might have a lot of output so forcing it to finish before continuing might lead to a better user experience that library authors could decide to provide. Users could opt out by capturing the promise.
3. This would allow library authors to change behaviour when it's used like this.

[dsherret]

I've been thinking about this more and adding an await keyword is really not that bad. Also received this feedback:

personally I'm not fan of adding repl specific behavior, so the code you write in the repl you can't just copy paste it into a file (you'll need to add back those await)

...and the more I think about it, the more I agree. Not providing an await keyword in the REPL creates a bad habit of not providing the await keyword in normal code. So I'm going to close this suggestion.