Front page | perl.perl5.porters |
Postings from January 2008
Hi all,
currently, it’s quite onerous to check whether a potentially
undefined variable is equivalent to a non-empty string. The
only way to avoid a warning is by the following test:
if ( defined $foo and length $foo ) { ... }
As a result, many people just shrug and write
if ( $foo ) { ... }
accepting that 0 and "0" will trigger false positives.
So I propose to change the behaviour of `length` when passed
undef: instead of returning 0 and throwing a warning when
`uninitialized` warnings, simply return undef in turn without
ever warning.
Because undef numifies to 0, the observed behaviour is very
nearly identical.
*However*, you can then write just the following:
if ( length $foo ) { ... }
Since undef in boolean context does not warn, this won’t either.
Additionally, since this makes the return value of `length`
differ for undef vs the empty string, you don’t need the original
string to be able to check whether it was undef, which might make
some rare cases simpler to write.
The only backcompat gotcha I can think of is that it may cause
warnings to be thrown in code written under the assumption that
the return value of `length` will never be undef. However, for
that to be an issue, `unitialized` warnings have to be enabled in
whatever part of the code uses the return value of `length` while
at the same time undefs are passed into `length` unguarded. That
sort of scenario seems extremely unlikely to exist. And even if a
few people do have code like that around, how bad is the problem?
They get `unintialized` warnings in code that deals with undefs
in unorthodox ways.
So this seems like a small change that will adversely affect next
to no one but will make it just that little bit less onerous for
everyone who tries to write more robust code. Sounds like a win
to me.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Thread Next