in reply to Empty qr// fails to match -- Is this known bug?

It's no bug, but a feature. Quote from perlop:

m/PATTERN/cgimosx

(...) If the PATTERN evaluates to the empty string, the last successfully matched regular expression is used instead. In this case, only the "g" and "c" flags on the empty pattern is honoured - the other flags are taken from the original pattern. If no match has previously succeeded, this will (silently) act instead as a genuine empty pattern (which will always match).

In this particular case, the last successfully matched regular expression is "(1)(2)". which matches neither "1" (i.e. $t), nor "2" ($u).

Replies are listed 'Best First'.
Re^2: Empty qr// fails to match -- Is this known bug? (bug)
by tye (Sage) on Oct 23, 2008 at 13:27 UTC

    No, I still say it is a bug. Especially since print qr// prints a non-empty string, (?-xism:), and /(?-xism:)/ is not interpretted as an empty regex. More to the point, this rather clearly violates the principle of "least surprise". It isn't even useful. I'd actually prefer that even /$empty_string/ not trigger the "empty regex" special behavior. But it seems very clear to me that /$empty_regex/ should not trigger this behavior.

    - tye        

      Right, the problem to me is that $U = qr/$some_user_provided_input/, and this is very unexpected behavior.

      I agree with tye and not almut: since "$U" ne "", /$U/ shouldn't be an empty pattern, so perlop's condition for empty // matching shouldn't apply.

      But after a bit of investigation, it seems that Perl always takes a shortcut: when $rx = qr/foo/, /$rx/ turns into /foo/. Which explains this behavior, but I still think it's a bug.

      The bug's in the stringification of qr//, if anywhere. The empty regex problem is (merely) an infelicity.

      I don't see why the stringified representation of a Regex would be given any importance here. To me, the whole point of compiled Regexes is that they are not string Scalars.

      Globals suck.

      Be well,
      rir

        It's still inconsistent. /$T$U/, which is *also* empty (if you ignore the stringified representation), doesn't act like an empty //.