Note: My answers are non-authoritative. Don't trust me.
> Can we please have a 'reverse x' modifier that means "treat whitespace as
> literals"? Yes, we are living in a Unicode world now and your data could
> theoretically be coming in from a different character set than expected.
> But there are times when it won't...when (for example), you wrote the data
> out yourself, or you're operating on files that are generated and
> maintained purely in-house, so they are guaranteed to be in the same
> character set as the Perl source code you're writing. I understand the
> arguments for the way the defaults are set. I even agree with them. But
> you will NEVER convince me that the first example below is not easier to
> read than any of the alternatives:
>
> /FATAL ERROR\: Process (\d+) received signal\: (\d+)/
I don't see how this example is nearly as flexible as this:
m:w/FATAL ERROR\: Process (\d+) recieved signal\: (\d+)/
Yours will only match 4 spaces after FATAL ERROR:, whereas mine will match
any number. While this is probably not necessary, what if the software
producing the messages decides to arbitrarily change this 4 to 5 in the
next version?
I see the :w modifier as a good flexibility enforcement. It will
keep people away from matching things that very literally.
> How are 'fail' and 'die' different inside a regex?
>
> Can subroutines that aren't used in regexen use 'fail' to throw an
> exception? If so, how is it different from 'die' when used outside a
> regex?
C<fail> is a special kind of C<die>, where it throws an exception that the
regex engine is expecting. When the engine catches it, it says that the
current part failed, and it should backtrack and try again.
C<die> throws whatever exception you tell it to (what's the default?),
which probably won't be caught by the engine. It will propigate outside of
the regex itself into the calling code, and up and up until someone
catches it.
Luke
