On Thu, Aug 23, 2012 at 10:31 PM, Damian Conway <damian@conway.org> wrote: > > I have also added in two overloading cases that we seemed > to have so far ignored: for unambiguous Num and Str. > > Thank you for adding those. The more I think about it, the more I'm comfortable not trying to fall back to 'eq' (with warning) for ambiguous scalar cases. The documentation should be telling people "use a literal on the RHS or explicitly cast to number/string or use some comparator sub/object which disambiguates". > And I'm still hoping that the final fallback case might return undef > (not "") so as to differentiate "unsmartmatchable" from > "smartmatchable, but didn't match". +1 I think the challenge inherent in the ambiguous RHS case is improved if we give people a way to detect it and respond appropriately. E.g. when { $lhs ~~ $rhs // $lhs ~~ "$rhs" } { ... } That allows any arbitrary RHS to attempt to match, and falls back to string RHS only if the RHS is ambiguous. That's an ugly idiom, but is explicit and works for those who need it. David -- *David Golden* <dagolden@cpan.org> *Take back your inbox!* → http://www.bunchmail.com/ Twitter/IRC: @xdgThread Previous | Thread Next