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

Re: fixing smartmatch just hard enough (and when, too)

Thread Previous | Thread Next
August 23, 2012 04:14
Re: fixing smartmatch just hard enough (and when, too)
Message ID:
On 23 August 2012 02:07, Damian Conway <> wrote:
> demerphq wrote:
>> It seem to me that the problem here is that the flag you speak of is
>> currently theoretical.
> Indeed. Hence the use of "putative" and "theoretical" in my descriptions.
>> IOW, any case where a string was numified, or a num stringified would
>> end up being ambiguous, and I think this happens a lot more than you
>> seem to suggest.
> I certainly wasn't suggesting that "ambiguous" variables are unusual
> (only that they may be easily disambiguated by explicit coercion).
> Indeed, I think that a significant percentage of variables in typical
> Perl code--maybe even most of them--may be dual-valued.
> But I note that this is a problem only when a "raw" variable is the RHS
> operand of a smartmatch...which may indeed still be unusual. In my
> experience, it's far more common for the LHS operand of a smartmatch to
> be the variable and for the RHS operand to be a literal or an expression
> of some kind.

Yes indeed that is probably true.

> I agree that this proposed workaround isn't perfect, but I think it's a
> very good compromise under the current limitations...and, perhaps more
> importantly, that it's perfectable in a forwards-compatible manner,
> should those "putative" and "theoretical" flags ever become "actual"
> and "realized". :-)

I was belaboring the point because i would really like to see the
latter happen, and it makes your plan work all the better.



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