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 definedness. Ashley Winters
