On Fri, Aug 24, 2012 at 8:12 AM, Eirik Berg Hanssen < Eirik-Berg.Hanssen@allverden.no> wrote: > 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? > You really raise two issues: (1) why do we resolve ambiguous 0+, "", qr// in favor of qr, but don't resolve ambiguous just 0+ and ""? Mostly, I think it's because for non-overloaded scalars, you can tell if a scalar has a reference to a regexp (or a reference to a coderef). It's arbitrary to put coderef before qr//, but you have pick one. Since those are reasonably unambiguous, they come before any ambiguous plain scalar case, where the language historically can't tell whether you meant number or string. (2) Why not prefer Num to Str if there is ambiguity? Because whatever we choose is going to seem wrong to some of the people some of the time. I proposed that Any ~~ Ambiguous do something arbitrary (I said 'eq') and warn. But no one seems to like that much. I now think that we're going to annoy/confuse people regardless, so we might as well just annoy/confuse *everyone* and make people be explicit instead. That's up-front pain that avoids subtle bugs later on. David -- *David Golden* <dagolden@cpan.org> *Take back your inbox!* → http://www.bunchmail.com/ Twitter/IRC: @xdgThread Previous | Thread Next