Spec |> await

[bakkot]

This specifies the third of the options here (I think).

I believe the inclusion of GetValue actually is observable because it means the running execution context is not suspended if the LHS is an abrupt completion, which is as I'd expect.

I'd be happier if we could prevent

a |> await
b

from parsing as

(a |> await);
(b);

(instead having it just be an error), but I can't see good way of doing that off the top of my head. The reason I want this is because it amounts to a "phantom" NoLineTerminatorHere restriction in AwaitExpressions which only applies in pipelines, which I don't really like.

[mAAdhaTTah]

I'm working on implementing this in babylon. Is the parsing issue you mention actually a problem? I'm actually wondering if banning |> await identifier and parsing |> await as a single.... step? operation?, such that following |> await with anything other than another |> terminates the pipeline.

So this:

x |> fetch
  |> await y
  |> process

would parse as:

x |> fetch
  |> await;

y |> process;

Would this be too surprising behavior? The other thought was making it a SyntaxError, requiring the next token after |> await to be either |> or ;.

@zenparsing I get what you mean by "ad-hoc" rules 😀.

[littledan]

@mAAdhaTTah I don't understand how that parse would happen. An expression followed by another expression, with a space in between, is a SyntaxError--ASI is only triggered by newlines.

[mAAdhaTTah]

@littledan Oh right, ok then. Is lookahead after |> await, requiring the next token to be ; or |>, a feasible solution? Then this:

a |> await
b

would be a SyntaxError, which would avoid an ASI hazard. Otherwise, I think we're stuck with the above behavior.

[littledan]

Seems like, if we merge this patch, it'll be in a branch that @mAAdhaTTah would maintain. Is that right? If so, should we close this PR?

[mAAdhaTTah]

@littledan Yeah, I'm going to borrow this change for the F#-style spec, which I'll maintain in our fork, but since we designed the current minimal proposal to ban await, this can't be merged until we make a decision on which proposal we're adopting.

[littledan]

@mAAdhaTTah Are you planning on writing an explainer in your fork that focuses on the vision of the F# proposal, and linking to this from the explainer in this repository?

[mAAdhaTTah]

@littledan Yeah, I'm working on that now, but I haven't committed anything yet.

[mAAdhaTTah]

This is implemented here.

[littledan]

Great, closing this PR for now then; we can reopen if we select the F# proposal.