Sorry for the newbie-ish question, but can someone explain why <op>=
does not warn? Is it because (quoting perlop)
$a += 2; is equivalent to $a = $a + 2; although without
duplicating any side effects that dereferencing the lvalue
might trigger
and the warn is considered a side effect? Or is it just a kluge to
support someone developer's personal preferences?
Is it possible to enable warnings for this case in 5.8? In my coding
style, I would consider it a bug to append to an undef scalar like in
Michael's example quoted below. The implicit conversion of $foo to the
null string before appending 42 is a no-no in my opinion.
Chris
Jeff 'japhy' Pinyan wrote:
> On Jun 14, Bart Lateur said:
>
>
>>On Fri, 14 Jun 2002 00:21:16 -0400, Michael G Schwern wrote:
>>
>>
>>>The history is someone noticed that since this:
>>>
>>> my $foo; $foo = $foo . 42
>>> Use of uninitialized value at -e line 1.
>>>
>>>and this:
>>>
>>> my $foo; $foo .= 42
>>>
>>>are logically the same, the former shouldn't warn.
>>
>>Perhaps... (I feel like disagreeing, though.)
>>
>>Anyway:
>>
>> my($foo, $bar); $foo = $bar . 42;
>>
>>*should* warn. Only in the exceptional case where the lvalue on the left
>>is identical to the lvalue first thing on the right, the warning might
>>be dropped. Well: it doesn't warn. That makes no sense at all, either
>>'.' should warn (pretty much) always, or never.
>>
>>And that's where my disagreement kicks in. The rules used to be much
>>simpler: '.' warns, '.=' doesn't. I feel that rule make much more sense,
>>"logically the same" or not. If you don't want the warning, use '.='.
>
>
> Yeah, if we start allowing undef values when they're being used for
> concatenation, we'll stop being warned when we might want to be. :(
>
