markstos++ pointed out the following behavior:
use v6-alpha;
{
when 1 ~~ 0 {
say "Surprise!"
}
}
This code prints "Surprise!", because $_ is undef, which is false, just
like 1 ~~ 0 is.
I'd like to make the following suggestions for Synopsis clarification:
1. It will be a very common pitfall, I think, to write C<when> as a
synonym for C<if>. For an extra layer of safety for such a novitiate
mistake, a boolean used as an argument to when should emit a warning
unless suppressed with an explicit C<?()>.
when 1 ~~ 0 # warning
when ?(1 ~~ 0) # no warning
2. I think C<when> should either be disallowed outside of C<given>, or it
should be made to do something useful. I have no strong opinion on which,
but I can see a smartmatching-against-topic construct being useful. So I
suggest the following:
Upon exit, C<when> emits a WhenExitSuccess control exception (a
subclass of the ExitSuccess exception thrown by other blocks)
C<given> catches WhenExitSuccess exceptions and immediately returns.
Other blocks ignore WhenExitSuccess exceptions (or usually just ignore
all ExitSuccess exceptions), so C<when something> acts exactly like
if $_ ~~ something
except C<when... else> is disallowed.
If this is allowed, I personally think a when statement modifier seems
reasonable too, but that's Larry's call.
If these semantics are not followed, I do think C<when> should be
disallowed outside of C<given> (or blocks of some other when-allowing
trait that given has but standard blocks do not). The "upon exit
immediately exit the surrounding block" semantics seem to be rather seldom
useful outside of C<given>.
Trey
