Normative: Ban |> await

Given problems with all possibilities considered for await integration
with pipeline, ban |> await within an async function as the initial
option. When we have considered things further, we could add await
integration as a follow-on feature.

Relates to tc39#66

Author: littledan

README.md

@@ -78,29 +78,7 @@ As you can see, because the pipe operator always pipes a single result value, it
 
 ### Use of `await`
 
-The pipeline operator allows a `Promise` to be `await`ed as follows:
-
-```js
-promise |> await
-```
-
-which is the equivalent of
-
-```js
-await promise
-```
-
-This is to allow you to `await` the result of an asynchronous function and pass it to the next function from within a function pipeline, as follows:
-
-```js
-const userAge = userId |> fetchUserById |> await |> getAgeFromUser
-```
-
-which is the equivalent of
-
-```js
-const userAge = getAgeFromUser(await fetchUserById(userId))
-```
+The pipeline operator does not have any special integration with async/await in its initial version, due to [issues](https://github.com/tc39/proposal-pipeline-operator/issues/66) with various alternatives discussed. To leave space for future additions to integrate await support, the not-very-useful sequence `|> await` (which would otherwise await a function, not the result of calling a function) is a SyntaxError.
 
 ### Usage with Function.prototype.papp
 

spec.html

@@ -34,20 +34,21 @@ <h1>Syntax</h1>
     <ins>
       PipelineExpression[In, Yield, Await] :
         LogicalORExpression[?In, ?Yield, ?Await]
-        PipelineExpression[?In, ?Yield, ?Await] `|>` LogicalORExpression[?In, ?Yield, ?Await]
+        [~Await] PipelineExpression[?In, ?Yield, ?Await] `|>` LogicalORExpression[?In, ?Yield, ?Await]
+        [+Await] PipelineExpression[?In, ?Yield, ?Await] `|>` [lookahead &lt;! {`await`}] LogicalORExpression[?In, ?Yield, ?Await]
     </ins>
   </emu-grammar>
 </emu-clause>
 
 <emu-clause id=sec-pipeline-semantics>
   <h1>Semantics</h1>
-  <emu-clause id=sec-pipeline-evaluation>
-    <h1>Runtime Semantics: Evaluation</h1>
-    <emu-grammar>PipelineExpression : PipelineExpression '|>` LogicalORExpression</emu-grammar>
+  <emu-clause id="sec-pipeline-evaluate">
+    <h1>Runtime Semantics: PipelineEvaluate</h1>
+    PipelineEvaluate for _lhs_ and _rhs_ performs the following steps:
     <emu-alg>
-        1. Let _argRef_ be the result of evaluating |PipelineExpression|.
+        1. Let _argRef_ be the result of evaluating _lhs_.
         1. Let _arg_ be ? GetValue(_argRef_).
-        1. Let _funcRef_ be the result of evaluating |LogicalORExpression|.
+        1. Let _funcRef_ be the result of evaluating _rhs_.
         1. Let _func_ be ? GetValue(_funcRef_).
         1. If Type(_funcRef_) is Reference, then
           1. If IsPropertyReference(_funcRef_) is *true*, then
@@ -70,6 +71,20 @@ <h1>Runtime Semantics: Evaluation</h1>
     <emu-note>All calls to eval from a pipeline operator are indirect eval calls.</emu-note>
     <emu-note type="editor">This definition is somewhat duplicated from the definition of evaluating CallExpression; when merging with the main specification, a refactoring will be done to de-duplicate it.</emu-note>
   </emu-clause>
+
+
+  <emu-clause id=sec-pipeline-evaluation>
+    <h1>Runtime Semantics: Evaluation</h1>
+    <emu-grammar>PipelineExpression : PipelineExpression `|>` LogicalORExpression</emu-grammar>
+    <emu-alg>
+        1. Let _result_ be the result of PipelineEvaluate for |PipelineExpression| and |LogicalORExpression|.
+        1. Return _result_.
+    </emu-alg>
+    <emu-grammar>PipelineExpression : LogicalORExpression</emu-grammar>
+    <emu-alg>
+        1. Return the result of evaluating |LogicalORExpression|.
+    </emu-alg>
+  </emu-clause>
   <emu-clause id=sec-pipeline-has-call-in-tail-position>
     <h1>Static Semantics: HasCallInTailPosition</h1>
     <emu-grammar>PipelineExpression : PipelineExpression '|>` LogicalORExpression</emu-grammar>