HaloO,
Luke Palmer wrote:
Recently, I believe we decided that {} should, as a special case, be
an empty hash rather than a do-nothing code, because that's more
common.
Ups, is that distinction needed eagerly? Wouldn't the return value
of a do-nothing code return a value that when coerced into hashness
result in an empty hash? Avoiding this superflous call is more of
interest to the optimizer than code correctness. OTOH, implementing
an empty block is easy as well.
However, what do we do about:
while $x-- && some_condition($x) {}
The {} obviously has no influence on the boolean result
tested by while. Why suddenly bother if it is a code or hash?
Same with {;} or { $x => random, foo => bar }. The lexer is
concerned with the closing brace terminating the while statement
and not an empty hash consumed by the return value of &some_condition
or whatever.
So the underlying question is how should
%hash = undef; # same as %hash = {}; ?
behave where I assume the undef is the return value of the
do-nothing code.
This touches again on the many meanings of undef and the question
if the above is a valid idiom to detach a hash container from its
former content, or if it indicates "don't touch %hash unless you
are prepared to catch an exception". And how long would such a
touchiness last? E.g. would
%hash<a> = 7;
blow-up but
%hash = { a => 7 };
cure the undef?
--
