With my decision to endorse SWITCH fallout, the idea of "CASE fallout" has come up:
>> case [
1 > 2 [...]
3 > 4 [...]
10 + 20
]
== 30
One of the things that makes it more palatable is the change needed to support elide...basically that you will be "seeing" the branches in the form of blocks (or ACTION! literals, if you composed them in, but you probably knew what you were doing if you did that).
But then, there was this question:
This lets you say:
block1: [...]
case [
1 > 2 (block1)
3 > 4 (func [x] [...])
10 + 20
]
You could do that with a COMPOSE (or a COMPOSEII). Which would be a slight performance cost, but arguably more clear...and we're trying not to stress out too much over performance at that level.
But the point is that it makes one a little less comfortable with the CASE fallout, because the blocks aren't as obvious in the structure. Of course, blocks can be arguments to the expressions in a case, so it's not a slam dunk anyway.
An argument against soft quoting would be based on what you would want CHOOSE to do with GET-PATH!, SET-PATH!, and group:
choose [
1 > 2 [literal block]
3 > 4 <tag>
5 < 6 (10 + 20)
]
Should that be (10 + 20) the literal group, or a way of choosing 30? If you want it to be the literal group, that seems to strongly suggest the branches in a CASE should not be soft quoted. And I kind of think I like the literal GROUP! outcome for CHOOSE, it feels more "solid" and predictable to really let you pick anything out of that slot.
I think I want to say that you need to use literal blocks in CASE, and if you have a non-literal one that should be done with COMPOSE. The performance argument doesn't hold up under scrutiny, because if you just use a BLOCK! with CASE that is going to be nearly as fast (within the noise, compared to the COMPOSE which would actually cost slightly more).