01:56
<Jack Works>
https://raw.githack.com/tc39/proposal-pattern-matching/new-spec/index.html
10:31
<mika_akizuki>
I was just having a bit of thought about allowing the await operator to be suffixed rather than prefixed (e.g. like .await in Rust)
10:34
<mika_akizuki>

This could make chaining more readable (reduced the need for parentheses), for example

// before
(await fetch()).props
await (await someAsyncMethod()).someReturnedAsyncMethod()

// after
fetch().await.props
someAsyncMethod().await.someReturnedAsyncMethod().await
10:36
<nicolo-ribaudo>
That feels similar to https://github.com/tc39/proposal-wavy-dot
10:45
<mika_akizuki>

Hmm, I didn't notice that. It is similar, but I think spelling out .await is a bit more readable than ~.?
There is another example:

async function someFunc() { /* do something and returns 3 */ }

// This produces the intended behavior though to me it feels somehow odd
await someFunc() + 5

// This is feel more natural since it is certain that we get an awaited result and added it by 5
someFunc().await + 5
10:45
<mika_akizuki>
Purely my opinion though
10:45
<nicolo-ribaudo>
Spelling out .await is already valid JS code, so we'd need different syntax anyway
10:46
<nicolo-ribaudo>
``` var o = { await: 2 } var two = o.await; ```
10:47
<mika_akizuki>
Oh, I incorrectly assumed that await cannot be used as a field name, my fault
10:47
<mika_akizuki>
Then maybe yes, the wavy dot is kind of what I wanted
18:55
<TabAtkins>
The pipeline operator ends up solving this as well - fetch() |> await ^^ |> ^^.props, etc
22:51
<ljharb>
or even await fetch() |> ^^.props, i think
23:04
<Mathieu Hofman>
Yeah pipeline operator removes some of the motivation for wavy-dot
23:36
<jmdyck>
Jack Works Disallowing (somehow) an ExprStmt that consists solely of a MatchExpr would avoid the ambiguity with MatchStmt, but there would still be conflicts between MatchStmt and any ExprStmt that starts with a MatchExpr.
23:57
<snek>
is it even possible to disallow it in that way, without infinite lookahead or smth?