The fallout from the SWITCH fallout feature

Development Internals
8

I'm going to come out in favor of the switch fallout feature. Reasons:

  1. Performance-wise, it is the fastest defaulting mechanism...faster than ELSE or SWITCH/DEFAULT.

  2. If people don't like it, they don't have to use it.

  3. Due to the nature of ELSE, it completes the left hand side of an expression. Sometimes when an expression can be completed you don't want it to...and this means you need <-, so for instance you have to write append x <- switch [...] else [code]. But with switch fallout, you can do it as append x switch [... (code)].

Point 3 is a reason to not blindly convert EITHERs into IF...ELSE. Or CASEs ending in true [...] to CASE...ELSE. Sometimes it's better to duck an arrow.

I've also noticed that CASE ending in true [...] can be more compact than a CASE...ELSE. That applies to the fallout switch too, it's just shorter.

(Note: As some have pointed out, writing /else [...] as your last "truthy" case is actually faster, because there's no variable lookup involved (true => #[true]), /ELSE is just "truthy" by nature. So we should probably prefer that as an idiom.)

Now a new question...

Should CASE also support fallout?

There've been some increases to the strictness of CASE. It now pretty much requires blocks for the clauses, and given that it does that, might we allow:

>> case [
       1 > 2 [...]
       3 > 4 [...]
       10 + 20
   ]
== 30

It would be consistent with SWITCH, and the risks of such a construct are much lower than they used to be. Note that since there's strict alternation, you couldn't say 10 + 20 30, it would measure that exactly one expression ran and then it either ends or there's a source-level block.

A lot of the same arguments for why it's good for SWITCH apply here, too. (And of course, useful for Code Golf...) Certainly the "you don't have to use it if you don't want to" seems a pretty strong point.

Update: Fallout from CASE committed

1 Like