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>.


Reply via email to