A change that made sense to me for SWITCH was that it should evaluate its switched-upon clauses.
This means that you get the power of the evaluator, hence things like ELIDE and DEFAULT can work. You can switch on things that are in variables:
var: 10
switch data [
9 [print "Ordinary cases work]
elide print "You can print here if it wasn't a 9"
var + 1 [
print "Able to use calculations...so switch on 11 here"
]
default [
print "DEFAULT works in concert with fallout due to evaluation"
]
]
But... one feature that does not work under this scheme as written is soft-quoted branching.
>> switch 1 [ 1 '[1 2 3] 2 '[4 5 6]]
== 1
This faces a kind of fundamental barrier, that QUOTED! is the only way to get your switch cases to suppress evaluation:
data: [#x b <y>]
switch second data [
'a [print "a"]
'b [print "b"]
...
]
We might consider making a construct that operates more like CASE and goes in value/branch pairs (CHOOSE?)
choose 2 [
1 ["a"]
2 '<b>
]
That would have some odd properties, in line with some of CASE's historical peculiarities:
>> choose lit 'b [
'a 'b
'b 'c
]
== c
CHOOSE wouldn't have that flexibility of falling through on multiple branches, but it could use the GROUP! mode of soft quote escaping to reuse a branch:
>> branch: [print "reusable"]
== [print "reusable"]
>> choose 2 [
1 + 1 (branch)
2 + 2 (branch)
]
reusable
And it would work with DEFAULT and ELIDE, etc.
I really am pretty attached now to how evaluative switch works. The unfortunate cost of that is that it doesn't fit into the soft-quoted branch model. :-/ I think that's just life--you can look at it and realize why it has to do what it does, it recognizes BLOCK!s only as branches.