Damian Conway wrote:
> > If one were looking for the first matching item, last would work:
> >
> > grep { /pat/ and last } @foo
> > # return()s the value of $_=~/pat/, which will be true
>
> Huh? I can't see how that could work unless you change the existing
> semantics of C<and> and C<last>.
No, only C<last>... and I think we're preparing to do that anyway, right?
> Let's take a step back and analyse the problem. We need a way to allow a
> ...
> *and* be consistent with existing semantics.
If feasible. Not otherwise.
> I would propose that the C<grep> operation should short-circuit if the
> block throws an exception, with the value of the expection determining
> whether the final invocation of the block should accept the element it
> was filtering:
Oh, no. perl catches user-thrown exceptions and attaches special semantics
to the exception value? That's a horrendous idea, completely unprecedented
in Perl. User-thrown exceptions should longjump directly to the enclosing
user-defined try block, nothing else.
What you're proposing to do with exceptions, I'm proposing to do with last.
I.e. your C< die 'foo'; > would be my C< 'foo'; last; >;
--
John Porter
We're building the house of the future together.
