What's blocking this from becoming a stage 3 proposal?

[MadaraUchiha]

As far as I can see, all of the other 4 issues have either reached a consensus or are non-issues.

What's currently blocking this proposal from advancing, and how can we unblock it?

[GaryGSC]

According to @rbuckton in this other comment, it's blocked (or at least was blocked) from advancement to stage 3 due to overlap with the do expressions proposal.

[MadaraUchiha]

#4 is about that, it doesn't give off the impression that it's blocked because of it, the two seem orthogonal. Perhaps @rbuckton could shed some light about what the actual issue is?

[dbartholomae]

Any news on this?

[devoto13]

It seems that the fact that either throw a+b behaves differently whether it is an expression or a statement or the new grammar for throw expression is needed is why it's not moving forward. And since it didn't get an update for a long time probably no good solution has been found.

See meeting notes here and here for more details.

[scf4]

Is this not going anywhere? :(

[neyb]

I think do expression proposal is more about IIF than "is throw an expression or a statement" (btw do expression proposal also question about if/else statement or expression... but that's another topic).

Sure it gets around the throw statement problem, but does resolve the root problem. Moreover it is still really immature and we won't see it before a while and they do not have any conflict.

To me, the question is 'should "throw x" be assignable to something or not ?'
I think you sould be able to assign it even if in practice it won't happens (this is the approach of every modern language i know) : assignation is not wrong because it won't happen.

let's list some arguments :

1. items.find(test) ?? throw new Error('not found') is too convenient while having to store result before returning it is verbose/polute mind/not function (need brace in arrow function)
2. Every project i work on either use babel to add throw expression or create a throwError function just to bypass the problem.
3. it is retro compatible
4. (not a real argument) every modern language that have exceptions do that (typed ones have a special type for it)

[Zarel]

I don't know if saying this here is very useful, but in case it is, I would want throw (and return/break/continue) expressions even if we had do expressions. throw ... is still shorter than do { throw ... }, which makes it more readable because of less distracting text.

[rattrayalex]

My read of the notes linked above is that there's near-consensus that throw is sufficiently useful as an expression to be separate from do, with one or two committee members dissenting.

Kevin Gibbons in particular seemed skeptical, and raised the bugbear of precedence issues (does throw a+b throw just a? When are parens required?) which are likely resolvable, but I'm not sure if iteration on the precedence of a throw expression has occurred since then.

I think the committee's sense (probably even Kevin Gibbon's sense) is that the community would strongly prefer to be able to use throw expressions to using throw statements in do expressions.

I may be misreading the notes, and those were from 2018 - I'm not sure if relevant discussion has occurred since.

[Zarel]

Ah, yes, I saw the discussion on operator precedence.

It seems like the main question there is: whether to require parentheses, or whether to have inconsistent comma operator precedence.

I would prefer the inconsistent comma operator precedence (alternatively, a weirder compromise: don't require parens unless it's followed by a comma, in which case require (throw a), b or throw (a, b)). I think parentheses make the code unnecessarily uglier to accommodate an operator basically never used. (People who read a lot of minified code can just memorize the difference...)

But honestly, I just want to be able to use this!

[Jack-Works]

I think it's very easy to resolve the problem of operator precedence.

Change the syntax from throw Expression to throw ( Expression ). Make it like a function call.

[Zarel]

@Jack-Works that's also an option, mentioned in #10 (comment)

I don't hate it, but I don't like it, either. I prefer having the same syntax for expressions and statements, and I don't think the comma issue is important enough to be worth requiring the parens. Even if we did require the parens, I'd prefer for them to be outside, like (throw Expression), than for the syntax to be different.

[rattrayalex]

Discussion of precedence belongs in a separate thread.

[forresthopkinsa]

Discussion of precedence belongs in a separate thread.

That thread is #10

[grabofus]

It's a very similar problem to await expression in my opinion. Following the same logic throw a + b should throw a only.

await Promise.resolve(4) + 2; // 6
await (Promise.resolve(4) + 2); // "[object Promise]2"

[ExE-Boss]

@grabofus

It's a very similar problem to await expression in my opinion. Following the same logic throw a + b should throw a only.

await Promise.resolve(4) + 2; // 6
await (Promise.resolve(4) + 2); // "[object Promise]2"

That would behave incompatibly with the throw statement:

throw Promise.resolve(4) + 2; // currently throws "[object Promise]2"