PWpwdisswordfishy·Dec 20, 2025
https://github.com/tc39/proposal-do-expressions
(Not to be confused with do notation)
In Rust's Block Patterntc39
proposal-do-expressions
HTML2017–2025
tc39 / proposal-do-expressions
proposal-do-expressions
Proposal for `do` expressions
21Distinct people
23Mentions
0Explicit recommenders
1.2KGitHub stars
What to know before exploring
What it is
Proposal for `do` expressions
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- tc39/proposal-pattern-matching · linked in 2 of the same discussions
- tc39/proposal-pipeline-operator · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year23 dated mentions
Observed mentions: 2017-10-24 08:27:55 UTC to 2025-12-20 10:17:09 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
23 sourcesFor “everything is an expression” https://github.com/tc39/proposal-do-expressions may be of interest, though discussion seems to have paused.
In Civet: A Superset of TypeScriptI often find myself using an immediately invoked function expression to handle the try catch const assignment issue, for example:
const result = (() => {
try {
return new URL(someString)
} catch {
return null
}
})()
It's not pretty though, and I think the do expressions proposal would rid my codebases of this pattern: https://github.com/tc39/proposal-do-expressions
In The problem with new URL(), and how URL.parse() fixes that> no pattern matching/switch expressions
They're still waiting on the do expression proposal for that (https://github.com/tc39/proposal-do-expressions), which has been in the bikeshedding stage for the past five years.
In TypeScript is surprisingly ok for compilersIf you’re willing to accept a little bit of extra syntax/ceremony, the `do` expressions proposal[1] is pretty much this (but it’s only stage 1 so who knows when/if it’ll land).
1: https://github.com/tc39/proposal-do-expressions
In CoffeeScript for TypeScriptThere's a dormant proposal about this: https://github.com/tc39/proposal-do-expressions
In Using {blocks} in Rust and Go for fun and profitHas that not been fixed since ES2015?
const a = 5;
console.log(a)
{
const a = 10;
console.log(a)
}
console.log(a)
5
10
5
What we are missing from say Rust in js is the blocks being expressions, though there is a proposal ("do expressions") to allow this:
const a = do {
if (b) { 5 } else { 10 }
};
https://github.com/tc39/proposal-do-expressions
In Using {blocks} in Rust and Go for fun and profit> They should repurpose `do` so that `do {}` (without the `while`) is an expression that you can put statements inside and return the last statement.
There's a proposal for precisely that. Unfortunately, only Stage 1 though.
https://github.com/tc39/proposal-do-expressions
In Pipe Operator (|>) For JavaScriptFor reference.
Pattern matching: https://github.com/tc39/proposal-pattern-matching
Do expression: https://github.com/tc39/proposal-do-expressions
Pipe operator: https://github.com/tc39/proposal-pipeline-operator
In The TC39 Process> Switch statements
JS has had switch statements for a long time. Do you mean switch "expressions" that can be used inline? It's not pretty but JS has long supported that too using either eval() "hacks" or IIFEs: https://stackoverflow.com/questions/32451049/is-eval-the-onl...
Do you mean pattern matching? There are two Stage 1 TC39 proposals with different approaches to it:
More hands-on/direct: https://github.com/tc39/proposal-pattern-matching
More indirect: https://github.com/tc39/proposal-do-expressions
> list comprehensions
There are several libraries with strong Iterator support today that while not syntactically gorgeous do great jobs at allowing you to write simple list operations. Off the top of my head are IxJS and iter-tools, but also classic mainstays like up to date versions of lodash and Ramda.
There's a Stage 2 proposal to b
Read the rest
ring more of them into "the standard library": https://github.com/tc39/proposal-iterator-helpers
There's also a Stage 2 proposal for an operator to make the syntax generally nicer no matter the library: https://github.com/tc39/proposal-pipeline-operator
> array slicing
Array.prototype.slice() was added back in ES2015: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Array.prototype.at() was "just added" in ES2022 for unary (single argument) "slice" (ability to use negative indexes): https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
If you prefer syntax to function calls, there's a Stage 1 proposal still live for that: https://github.com/tc39/proposal-slice-notation
> better equality operators
That ship has probably sailed. Most projects at this point just have linter rules to standardize everything to the more reliable "triple equals" (===, and !==).
There are proposals for more structural equality functions in the standard library, though, for instance: https://github.com/tc39/proposal-array-equality
I've always found these approaches to writing conditions in JSX to be terrible. Wouldn't it be nice if JavaScript were an expression-oriented language? Then you could just write:
{if (gallery.length) {
<Gallery slides={gallery}>
}}
There has been a "do expressions" proposal [0] for many years, which addresses this (though it is more verbose). I hope it will be accepted some day.
[0] https://github.com/tc39/proposal-do-expressions
In Advice on JSX Conditionalshttps://github.com/tc39/proposal-do-expressions
Allows you to contain temporary variables to where they are needed, rather than having them remain active through the remainder of the current scope. You could do that with immediately invoked function expressions, but they are too verbose to be really viable for this. You could also use extra functions, but extra functions don't always make sense. Currently I'm frequently doing this:
Without do expression:
let result;
{
let tmp = 123;
result = tmp * 2;
}
With do expression it would become this:
let result = do {
let tmp = 123;
tmp * 2;
}
In Deno Joins TC39The TC39 process is well-documented, you can check out the stages and guidance for providing input here: https://tc39.es/process-document/
The do expression proposal is currently stage 1, so its very early. You can check out the issue tracker there to see some of the related discussion. Standards work can be deceptively hard, even for simple things. I think the do expression proposal is a good example of that.
Edit: forgot to link to the issue tracker I referenced above https://github.com/tc39/proposal-do-expressions/issues
In Deno Joins TC391. Pipe proposal doesn't make anything deeply immutable either. In JS you can even use a curly braces block to avoid leaking your let/const variables.
2. I am dreading even thinking about how the pipe thing is supposed to operate on JSX. There's the do-expression proposal to achieve what you want in a sane way: https://github.com/tc39/proposal-do-expressions
In A proposal for adding a pipe operator to JavaScriptThere is actually a Stage 1 proposal that introduces an expression that does _exactly_ that (because it's not as easy as just making `const x = for(let i of foo) { yield i; };` parse.)
https://github.com/tc39/proposal-do-expressions
https://babeljs.io/docs/en/babel-plugin-proposal-do-expressi...
In A case study on strict null checksShowing the 15 most recent of 23 sources. Enable JavaScript to search and browse every indexed mention.