On Sat, Nov 5, 2011 at 7:25 PM, John W. Krahn <jwkr...@shaw.ca> wrote:
> Brian Fraser wrote: > >> On Sat, Nov 5, 2011 at 3:54 PM, Shawn H Corey<shawnhco...@gmail.com> >> wrote: >> >> On 11-11-05 02:40 PM, Brian Fraser wrote: >>> >>> See `perldoc readline`. $! will be undefined if no error occurs. >>>> >>>> No. >>>> >>> >>> $! will be undefined, not `undef` >>> >>> That's silly. Perl has no spec -- You can't have undefined behavior. You >> can tell exactly what's going to happen if you look at the source. >> > > perldoc perlsyn > [snip] > > NOTE: The behaviour of a "my" statement modified with a statement > ^^^^^^^^^^^^^^^^ > modifier conditional or loop construct (e.g. "my $x if ...") is > ^^ > undefined. The value of the "my" variable may be "undef", any > ^^^^^^^^^ > previously assigned value, or possibly anything else. Don't rely > on it. Future versions of perl might do something different from > the version of perl you try it out on. Here be dragons. > > > > Not anymore it's not : ) $ perldoc perlsyn | grep NOTE But yes, I was being disingenuous -- Scalar context sort is "undefined" too, as is state @x = (list). In both cases it's meaningless*. It's not -documented-, but it's defined in the same way everything else in Perl is defined, by the implementation. Tacking an undefined in front is just another way of marking a feature as, say, "experimental" -- Merely a sign saying "This might change/This is an accident, don't rely on it", without having to go into the specifics of the current behavior. As an interesting aside, scalar context sort returns undef and doesn't evaluate it's operands. Running the shiny new bisecting tool that comes with the Perl repo shows that it has behaved like that as far back as the tool can go, which is 5.002 or 5.004, I think. [*] truncate() and func($i++, $i++, $i++) are also undefined. Those two are different because the behavior comes from how the C underneath the surface deals with things, not Perl itself.
