Occasionally, people lament that Perl has no switch/case statement like C. Perl6 has given/when, which goes several steps beyond the simple switch by handling arbitrary conditions, rather than simple equivalence.

So what does it buy you over if-else? Not a lot, in my experience. You can save some keystrokes by not retyping what you're matching against, and sometimes the ability to control whether things "fall through" -- matching multiple cases -- can come in handy.

Of course, we are not entirely without alternatives in Perl5. For simple multi-candidate equality testing without defaulting or fall-through, you can use a hash:

Developing this, I originally wanted to have the simpler syntax of when {cond-block} {then-block} but prototypes won't let me do that. You can only get one block interpreted as an anonymous sub without specifying sub, so i had to introduce the then pseudokeyword.

The same thing is what makes the grep solution so clunky. So meditation #2: we need a qsub operator. You put blocks of code after it, and it gives you a list of coderefs back. Then the arguments to grep look like:

Ah, the 'break'. Well, its value doesn't matter, so I could just stick {} in there instead. Or parenthesize qsub's list and stick a comma before 'break'...or qsub could leave things that aren't in braces alone. Smartqsub. Want to include a hashref in your list? Stick a + on the front, or put it in parentheses.

Update: Hold the phone! You don't need a new operator! You just need new semantics: if a block appears before or after any other object in list context, and they're not separated by a comma, the block is a coderef. Normal executable blocks are in void context; hashrefs will either appear separated by commas or alone. Nothing breaks. Right? [Wrong: indexing of hashes breaks (or at least becomes ambiguous): (1, $hash {'index'}) — dang.] Hashrefs adjacent to coderefs can be disambiguated with the old + trick.

Occasionally, people lament that Perl has no switch/case statement like C. Perl6 has given/when, which goes several steps beyond the simple switch by handling arbitrary conditions, rather than simple equivalence.

One drawback of Perl6's given/when over a "simple" switch is that given/when is just a glorified if/else chain. Perl will have to check each clause in order to find a matching one. Years ago, I programmed in a language (some kind of Pascal/C bastard) where constructs like:

There's no reason an if/else chain can't be optimized to a jump table where appropriate. In fact, Perl 4 did that optimization, though we never got around to putting it into Perl 5. Anyway, if you think Perl 6's switch structure precludes such an optimization, you are simply wrong. There's no reason to test any expression that you already know the results of, so such a Perl 6 switch statement can be made just as fast as a C-style switch statement if you limit the cases to constants. But Perl can extend the optimization to the case of strings with unique prefixes, and to ordinary if/else cascades as well, while retaining all the benefits of cascading logic in the more dynamic cases.

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other