On 12/17/05, Sebastian <[EMAIL PROTECTED]> wrote:
> Obviously there are mixed opinions of how undef should be treated and
> some won't be happy with what becomes final, so implementing some
> intelligent defaults and simple pragmas, but not excluding the ability
> to *really* control your undefs, sounds like a win-win.

If we want to have our cake and eat it too, let's create a new value: nil.

my $dog = nil;
ok !$dog;
ok $dog eq '';
ok $dog ne 'foo';
ok $dog == 0;
ok $dog != any(1..100);
ok $dog === nil;
ok ++$dog == 1;
ok not $dog === nil;

Explicitly nil values wouldn't warn or fail on activities which undef
does. nil is basically a value which is simultaneously '' and 0 and
0.0 and false *and* defined, and allows itself to be coerced with the
same rules as perl5 undef, but without an 'uninitialized' warning.

Uninitialized variables would remain undef, and would have Larry's
unthrown-exception failure rule. The nil value is completely defined
as above. And, huffmanly speaking, most people who want to explicitly
initialize a variable to an empty state are going to want nil, not
undef. C<my $var = undef> is redundant, after all -- as is C<$var //
undef>. When used as a value, undef returns C<nil but
E::UndefinedValue> or something. Thus completes the circle of

Ashley Winters

Reply via email to