On Mon, 02 Aug 2010, Ben Morrow wrote: > Quoth jand@activestate.com ("Jan Dubois"): > > On Mon, 02 Aug 2010, Zefram wrote: > > > > > > Nicholas Clark wrote: > > > >And so we go full circle, as you removed the code demonstrating that we > > > >already have that bug, only worse: > > > > > > Yes. We should fix that bug, not do it intentionally. > > > > I don't see agreement on what the bug is anymore: > > > > a) Should -0 always be TRUE, even when it has never been stringified, or > > b) Should -0 always be stringified as "0" and therefore always be FALSE? > > There is a third option: > > c) Add "-0" to the list of strings that are FALSE. > > (And, of course, arrange for "-0" to consistently numify as -0.0, if it > doesn't already.) And thus begins the slippery slope of adding more things that should evaluate to FALSE. Surely you want "+0" to be FALSE as well so that -$a always has the same truth value as $a, and $ perl -wle '$a="-0"; print -$a' +0 > This would only be a sane thing to do if we intend to make -0.0 consistently > useful. If the sign disappears (or reappears) under unpredicatble > circumstances, there's no point preserving it in the stringification > (that is, option (b)). It seems everybody who has commented so far seems to prefer (b) over the status quo. Should we change it and see if we get any blead-breaks-cpan pushback? Cheers, -JanThread Previous | Thread Next