On 2010-07-31, at 12:47 pm, Patrick R. Michaud wrote:
> On Sat, Jul 31, 2010 at 10:56:47AM -0600, David Green wrote:
>> given $something {
>> when True { say "That's the truth!" }
>> when 42 { say "Good answer!" }
>> when "viaduct" { say "You guessed the secret word!" }
>> }
> I'm not so sure about this. There's an argument to be made that the C<when
> 42> and C<when "viaduct"> cases should never be reachable, since both C<42>
> and C<"viaduct"> are considered "true" values...
Oops, no, I don't want it to do a value-and-type-check. I guess in this case
the "when True" could be moved last, but it's still not a great example.
Aaron's example with "when True" as a fallback at the end of a block is better.
> [re Aaron's example with: if time > $limit { say "tick" } ]
> The problem with this formulation is that a successful 'when' exits the
> block, while a successful 'if' does not. This is one of the significant
> differences between 'if' and 'when'.
It's possible to break out with an explicit "leave" or "succeed". Slightly
less elegant, but still straightforward and it doesn't require any exceptions.
And it makes the different tests look different.
Meanwhile, from one of your earlier replies:
> The problem is that there are at least two interpretations of a true result
> of <expr>:
> when True { ... } # execute when $_ is exactly "True"
> when foo() { ... } # execute when foo() returns true
Except that the latter 'when' isn't executed when foo() returns true; only when
it returns True! Well, maybe by "true" you meant "Bool::True" -- after all,
that's a comment, not code; or maybe you were even thinking "True" and the
lowercase T was a typo. At any rate, it confused me for several moments.
-David
