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.