C<when> outside of C<given>

[Trey Harris]

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

[Mark Stosberg]

Trey Harris wrote:
> 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.

To refine this point a bit, the spec is clear that 'when' is useful not
just with 'given' but with "any block that sets $_".

I agree that it should be an error outside of "any block that sets $_",
and I ask that that "any block that sets $_" be further defined. "for"
statements and method bodies are mentioned explicitly, but it would be
nice to have something approach a complete list.

Mark

[Mark J. Reed]

On 9/7/06, Mark Stosberg <ma...@summersault.com> wrote:
>
> To refine this point a bit, the spec is clear that 'when' is useful not
> just with 'given' but with "any block that sets $_".
>
> I agree that it should be an error outside of "any block that sets $_",

I disagree. I don't see aproblem with having it usable anywhere and just
always testing the current value of $_, whatever it may happen to be; if $_
hasn't been set at all, that would be caught by a standard check for use of
uninitialized variables (presumably available pragma-tically at least). So
I don't see a need for a specific restriction on the use of "when".

--
Mark J. Reed <mark...@mail.com>

[Trey Harris]

In a message dated Thu, 7 Sep 2006, Mark Stosberg writes:
> To refine this point a bit, the spec is clear that 'when' is useful not
> just with 'given' but with "any block that sets $_".

Thanks, I was not being terribly precice when I conflated when with given.
Of course, CATCH is another case where when is frequently used (and where
the semantics of when should be like given, exiting the surrounding block
once the when block has finished).

Trey