Eric Roode wrote:
>
> Allow me to throw another log on the fire:
>
> my $x;
> if (something)
> {
> $x = 1;
> }
> my $y = $x;
>
> This would give a compile-time warning under your RFC, warning the
> user of a possibly uninitialized $x. Okay. Next:
Yes.
> my $x;
> if (something)
> {
> $x = 1;
> }
> else
> {
> $x = 2;
> }
> my $y = $x;
>
> Would this give the same warning? Would it notice that $x is set
> in both branches of the condition?
Yes, it would notice this and not warn. All paths of flow control
leading to the final statement contain an initialization.
> Worse:
>
> my $x;
> if (something)
> {
> $x = 1;
> }
> if (!something)
> {
> $x = 2;
> }
> my $y = $x;
>
> I presume this would generate a warning under your RFC, right?
Yes. And not necessarily a spurious one: consider using $dsoifjd++ for
'something'.
> Since I would guess the compiler shouldn't be required to notice
> that one condition is the inverse of the other?
It would also have to prove that the value of 'something' does not
change from one call to the next.
> I'm not sure I like the above construct not behaving identically
> to the second case (if...else...) above...
The "possibly" version would need to be optional (or more optional) than
the others. As soon as it gave me even one spurious warning, I would
immediately turn it off except to periodically turn on all warnings full
blast to get a "lint"-like effect.
> Moving on:
>
> my $x;
> if (thing1)
> {
> $x = 1;
> }
> elsif (thing2)
> {
> $x = 2;
> }
> elsif (thing3)
> {
> $x = 3;
> }
> else
> {
> $x = 4;
> }
> my $y = $x;
>
> Warnings, or no?
No warnings.
> How about:
>
> my ($x, $i);
> for ($i=0; $i<10; $i++)
> {
> $x .= $i;
> }
> my $y = $x;
>
> Now, I can look at that and see that $x will be '0123456789', but
> the compiler can't be expected (imho) to know whether the loop
> condition will ever execute, so under your RFC it will generate a
> "possibly uninitialized" warning, right?
Right. We could stray from correctness here and assume any for loop is
executed at least once, but I'd rather not -- this is the code pattern
where it is most useful (because often the programmer doesn't notice
that, in fact, that for or while loop might not execute, in some weird
case.)
In this particular case, it might not be unreasonably difficult to ask
the question of "is COND true immediately after INIT in for(INIT; COND;
INCR)?" But the compiler certainly won't be that smart in version 1.
