relationship with do expression proposal

[Jack-Works]

it seems like can be done with do-expr proposal: (I didn't check the completion value of switch stmt so I don't know if it really works)

const val = do {
    switch (x) {
        case 1: "1"; break;
        case 2: "2"; break;
   }
}

[ljharb]

This is the correct answer to any attempt to make statements usable in expression position, imo.

[Jack-Works]

So you'd like to remove switch support in do expression just like for statement in do expression?

[ljharb]

@Jack-Works no, i think it makes sense for it to work in a do expression - I'm saying that "do expressions" should be the only path forward for all current statements being usable in expression position.

[Jack-Works]

So what about this? https://github.com/tc39/proposal-throw-expressions

[ljharb]

The committee decided that was the one exception, but i personally don’t think that proposal should have advanced at all - i just didn’t choose to block it.

[hax]

Though do works, it actually have a worse readability than this proposal, due to weird value; break pattern vs explicit return value.

[ljharb]

I’m not sure why you’d ever need break writing idiomatic code inside a do expression.

[hax]

I don't understand. What "idiomatic code"?

[ljharb]

If you mean the term, from a quick google:

Idiomatic code is code that does a common task in the common way for your language.

As for which code, I’m referring to the code you referenced that would use a weird break pattern.

[hax]

I mean, as Jack's code show, if u want to use do { switch ... } you always need such weird break pattern.

I think both of us could agree such break pattern is weird and bad. So the question is, whether it's the issue of do expression or switch.

I guess you will say it's only the issue of switch, but I think do expression also have issue, because such weirdness is not only switch, but also for (even worse) and finally, and if without else (not very bad, but still...). The problem behind it is we losing the explicit return in do expression compare to current IIFE pattern.

[hax]

...continue

And this is why the author of this proposal want

const color = switch(type) {
  case 'apple':
    return 'red'
  case 'banana':
    return 'yellow'
  default
    return 'invisible'
}

it could also apply to for and if cases.

I don't mean to support this proposal, but I'm trying to understand the logic and the real requirements/preference behind this proposal.