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
|
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
|
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? |