On Fri, Aug 24, 2012 at 1:20 PM, Abigail <abigail@abigail.be> wrote: > Besides, if someone were to use: > > $var ~~ $x; > > and $x could be a number or a regexp, but in one of the runs gets served > the above warning (because this time, the code path has printed out $x), > and changes it to: > > $var ~~ 0 + $x; > > it ain't going to work well in case $x is a regexp (or a coderef, or has > overloaded ~~ but not +, or has overloaded +, or several other cases), is > it? > Thank you. I knew there was something about this Num vs Str that bugged me, but I could not put my finger on it. Still not quite hard enough, this fixing. Still a misfeature in my book. ... remind me, why was the looks_like_num-treat-like-num dropped? Say we have an object that overloads qr//, 0+, and "". The current proposal would prefer the qr//. Say we have an object that overloads 0+ and "". The current proposal would refuse to state a preference, instead smartmatching "as a Num only if it is unambiguously numeric". What was the reason it should not prefer Num (whether overloaded or looks_like_num) to Str, the same way it prefers qr// to either? EirikThread Previous | Thread Next