On Tue, Jun 30, 2009 at 02:11:50AM +1000, Paul Fenwick wrote:
>
> These all seem to relate to how 5.10.1 smart-match handles undef. In
> particular:
>
> undef ~~ 0; # True! (undef is coerced to 0)
> undef ~~ ""; # True! (undef is coerced to "")
>
> Consequently, this also means the following prints "I've got a zero".
>
> my $x = undef;
>
> given ($x) {
> when (0) { say "I've got a zero!" } # printed
> default { say "I've got something else" }
> }
>
> This means that for 5.10.1, any given/when block is going to need a separate
> case for undef before any string/numeric tests if we want to avoid treating
> it like 0/"". I don't know about everyone else, but I *never* want to treat
> undef as if it's defined. If I did, I have now have the new // (defined-or)
> operator to make that easy. As such, it's a *big* surprise to have
> smart-match go coercing undef so readily.
I think no matter what choice will be made (undef is separate from 0/"";
undef is coerced to 0; undef is coerced to ""), you will encounter
situations where you wished the other choice was made. From experience,
sometimes I want 'undef' to be different from 0 and/or "". Often I want
'undef' and "" to be the same, but different from 0 (// isn't helping
there - a 'length' which doesn't warn on undef would help). Other times,
I want any false scalar value to be lumped together.
Therefore, I have no opinion on whether
undef ~~ 0
and/or
undef ~~ ""
should be true or false. Any choice will be surprising for some, and obvious
for others.
As long as there's some consistency.
Abigail
Highlight