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

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        

Replies are listed 'Best First'.
Re^3: Empty qr// fails to match -- Is this known bug? (bug)
by chibiryuu (Beadle) on Oct 23, 2008 at 15:04 UTC

    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.

Re^3: Empty qr// fails to match -- Is this known bug? (bug)
by chromatic (Archbishop) on Oct 23, 2008 at 17:39 UTC

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

Re^3: Empty qr// fails to match -- Is this known bug? (bug)
by rir (Vicar) on Oct 23, 2008 at 16:23 UTC
    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 //.
        Oh my, oh my $var if 0; another odd bug with desirable behaviour.

        Be well,
        rir