develooper Front page | perl.perl5.porters | Postings from January 2012

Re: [perl #108780] overload::StrVal and qr//

Thread Previous | Thread Next
January 22, 2012 14:36
Re: [perl #108780] overload::StrVal and qr//
Message ID:
On 22 January 2012 21:57, Father Chrysostomos <> wrote:
> # New Ticket Created by  Father Chrysostomos
> # Please include the string:  [perl #108780]
> # in the subject line of all future correspondence about this issue.
> # <URL: >
> According to the overload documentation, overload::StrVal returns the string that "" would return in the absence of string overloading.
> But this isn’t actually the case:
>    $\ = "\n";
>    use overload;
>    no overloading;
>    print qr//;                   # prints (?^:)
>    print overload::StrVal(qr//); # prints Regexp=REGEXP(0x803e50)
> qr// thingies are not actually using overloading.

They used to I think. And I think they should act like they are.

> overload::StrVal pretends that they are.

I would expect that it does.

> The overloading pragma knows they are not.
> Should one of overload::StrVal and change to match the other?

This one is tough. The normal stringification behavior of a qr//
object is supposed to be the pattern, however one should also IMO be
able to get the form returned by overload::StrVal somehow.

> Or should the we just document this oddity?
> This discrepancy is unfortunate, as it prevents this type of simplification:
> commit 8f6eeb4da8aeaa8cbb3b291181bdac4515d92e2d
> Author: Father Chrysostomos <>
> Date:   Wed Jan 18 13:03:32 2012 -0800
>    In overload::AddrRef, use ‘no overloading’
>    This speeds this up by about 13 times.

Yes that is unfortunate. I don't know if there is tricky way to make
this happen. One might almost argue this a regression from when qr//
objects where turned into first class SV types.

Wonder what Nicholas says.

perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About