Working example code:

    (async () => `Homepage: ${(await fetch(location.href)).status}`)().then(console.log)

Ideal example code:

    `Homepage: ${(await fetch(location.href)).status}`

Deleted: Screen Shot 2016-10-22 at 7.45.25 PM.png 69.7 KB

	Screen Shot 2016-10-22 at 7.45.25 PM.png 69.7 KB View Download

async functions will be shipped in Chrome 55.

I'm using Canary - you can see they are clearly supported in the screenshot, just not at the top-level.

await expressions must be in an async function, they cannot appear at the top-level by themselves.

Aleksey, can we do something useful here?

Not sure if I'm way off track here: as far as I know, code entered via the console is already evaluated within a function. I'm simply suggesting that be made an async function. The semantics of global await don't really apply within a REPL since it's not trying to faithfully replicate a global execution context.

We don't wrap expression in console with function or with any other synthetic blocks - just run code as is. You can think about every new command in console as <script>.. command ..</script> added to page.
JavaScript in future will probably use top level await for modules or something else and there is no plans to support top level await in spec [1].
I'm worried that by allowing await in console we can teach users to use await in this manner in script body for example.
In general I'd like to avoid any big difference between result of executing code in console and in global scope with <script> tag.

[1] https://github.com/tc39/ecmascript-asyncawait/issues/9#issuecomment-127427447

Sorry for asking, but do you have a reference to the (devtools?) source
where I can see how the REPL evaluates input?  It seems strange it can
support things like $0 and $() despite that being only available in
DevTools.

Feel free to ask any questions! I'm happy to answer.

We pass string to DevTools backend which is located in V8 [1]. Here we compile and evaluate this string as regular script. Right before evaluation of string on global object we install our command line API ($0, dir(), ...) [2]. It is installed with using of native V8 API [3]. Right after evaluation we removes installed command line api methods.

One year ago we used synthetic with block: "with(commandLineAPI) { evaluate(expression); }". We migrated to another way of injecting command line api to make possible using of some ES6 features in our console like let, const, classes (they don't work inside of with block).

[1] https://cs.chromium.org/chromium/src/v8/src/inspector/v8-runtime-agent-impl.cc?rcl=0&l=297
[2] https://cs.chromium.org/chromium/src/v8/src/inspector/v8-runtime-agent-impl.cc?rcl=1480609640&l=289
[3] https://cs.chromium.org/chromium/src/v8/src/inspector/v8-console.cc?rcl=1480609640&l=894

Ahh, perfect. I didn't realize it was able to inject those via the V8 API.

 Issue 673441  has been merged into this issue.

Issue 675967 has been merged into this issue.

> I'm worried that by allowing await in console we can teach users to use await in this manner in script body for example.
> In general I'd like to avoid any big difference between result of executing code in console and in global scope with <script> tag.

I wonder if there is some way to allow for top-level await to support easy debugging of async code without leading developers into bad habits?  Perhaps a checkbox or setting that enables it but is disabled by default?


As a workaround for this, developers can create a function that wraps up the async code:
```
var wrapper = async (awaitable) => { var result = await awaitable(); console.log(result); }
```

Callsite:
```
wrapper(() => fetch(location.href));
```

Unfortunately, this is only marginally better than the original proposed workaround and requires that function be added at some point.

Just an update - Safari allows top-level await in their console:
https://twitter.com/JosephPecoraro/status/832062592113745920

Deleted: C4wSGNhVYAAe5mr.png 46.9 KB

	C4wSGNhVYAAe5mr.png 46.9 KB View Download

Deleted: DAg-KCEXsAQuvKv.jpg 19.4 KB

	DAg-KCEXsAQuvKv.jpg 19.4 KB View Download

They support it only for single expression. If you start typing something like
var r = await fetch(...);
var json = await r.json();
..

or like:
console.log(await fetch());

As far as I know it doesn't work. I think we prefer to have full await support or don't have it at all.

Node seems interested in supporting this as well:
https://github.com/nodejs/node/issues/13209

 Issue 727924  has been merged into this issue.

> I think we prefer to have full await support or don't have it at all.

Latter please. Also notice https://github.com/nodejs/node/issues/13209#issuecomment-305125368

 Issue 733619  has been merged into this issue.

You might have a look at the library I implemented in <https://rafaelgieschke.github.io/await.-variables/>, which kind of takes comment 17 to the extreme and allows you to execute `await. a = fetch("/")` (instead of `a = await fetch("/")`) in the console.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e8111c396fef38da6654093433b4be93bed01dce

commit e8111c396fef38da6654093433b4be93bed01dce
Author: Alexey Kozyatinskiy <kozyatinskiy@chromium.org>
Date: Fri Aug 11 00:28:29 2017

[DevTools] support top-level await in console

If expression could be successfully compiled without preprocessing -
we do nothing.
Otherwise if function contains await expression:
  - if variable is var or variable is top-level we remove variable kind
    to make it available in global scope.
  - function definitions: function foo() {} -> foo = function foo() {}
  - top-level class definitions: class Foo {} -> Foo = class Foo {}

R=lushnikov@chromium.org,loue@chromium.org

Bug:  chromium:658558 
Change-Id: I8e9d26b93c3e53a966e43ec9c72b931a45c1a294
Reviewed-on: https://chromium-review.googlesource.com/601509
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Andrey Lushnikov <lushnikov@chromium.org>
Cr-Commit-Position: refs/heads/master@{#493612}
[add] https://crrev.com/e8111c396fef38da6654093433b4be93bed01dce/third_party/WebKit/LayoutTests/http/tests/devtools/console/console-top-level-await-expected.txt
[add] https://crrev.com/e8111c396fef38da6654093433b4be93bed01dce/third_party/WebKit/LayoutTests/http/tests/devtools/console/console-top-level-await.js
[add] https://crrev.com/e8111c396fef38da6654093433b4be93bed01dce/third_party/WebKit/LayoutTests/http/tests/inspector-unit/preprocess-top-level-awaits-expected.txt
[add] https://crrev.com/e8111c396fef38da6654093433b4be93bed01dce/third_party/WebKit/LayoutTests/http/tests/inspector-unit/preprocess-top-level-awaits.js
[modify] https://crrev.com/e8111c396fef38da6654093433b4be93bed01dce/third_party/WebKit/LayoutTests/inspector/sources/debugger-ui/show-function-definition.html
[modify] https://crrev.com/e8111c396fef38da6654093433b4be93bed01dce/third_party/WebKit/Source/devtools/front_end/console/ConsolePrompt.js
[modify] https://crrev.com/e8111c396fef38da6654093433b4be93bed01dce/third_party/WebKit/Source/devtools/front_end/console/module.json
[modify] https://crrev.com/e8111c396fef38da6654093433b4be93bed01dce/third_party/WebKit/Source/devtools/front_end/console_model/ConsoleModel.js
[modify] https://crrev.com/e8111c396fef38da6654093433b4be93bed01dce/third_party/WebKit/Source/devtools/front_end/formatter/FormatterWorkerPool.js
[modify] https://crrev.com/e8111c396fef38da6654093433b4be93bed01dce/third_party/WebKit/Source/devtools/front_end/formatter_worker/FormatterWorker.js
[modify] https://crrev.com/e8111c396fef38da6654093433b4be93bed01dce/third_party/WebKit/Source/devtools/front_end/sdk/RuntimeModel.js
[modify] https://crrev.com/e8111c396fef38da6654093433b4be93bed01dce/third_party/WebKit/Source/devtools/front_end/sources/SourcesPanel.js
[modify] https://crrev.com/e8111c396fef38da6654093433b4be93bed01dce/third_party/WebKit/Source/devtools/front_end/unit_test_runner.json