Docs: Section on local variables

[H. S. Teoh]

On Sat, Apr 21, 2012 at 02:14:14AM -0700, Jonathan M Davis wrote:
> On Saturday, April 21, 2012 01:38:22 Nick Sabalausky wrote:
> > "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
> > news:mailman.2003.1334971962.4860.digitalmars-d at puremagic.com...
[...]
> > > I didn't say that it couldn't. I said that there was no way that
> > > it would.  It would break a lot of code, and it goes completely
> > > against D's current approach of default-initialization everything.
> > > I'd be shocked if Walter agreed to making the compiler give an
> > > error for variables which aren't either assigned to or directly
> > > initialized before they're used. init solves the problem already.
> > > There's no need to do what C# and Java do on top of that.
> > 
> > I agree that it's never going to happen in D, and I can even live
> > with that.
> > 
> > However, .init definitely does *NOT* solve the problem. The problem
> > is "variables being read before they're properly initialized". The
> > .init value is NOT ALWAYS the proper initialization value. We *all*
> > know that: that's why we *have* initializer syntax.
> > 
> > I'm not going to try to argue for D to start doing C#-style
> > initialization checks. That ship has unfortunately sailed. But we
> > need to put a stop to this absurd myth that .init "solves the
> > problem". It doesn't do a damn thing more to solve the problem than
> > what "indent scoping" does to solve "improper indentation" - it
> > takes a catchable programmer error, replaces it with a subtle bug,
> > and exclaims "Fixed! See, no more error!".
> 
> init solves the larger problem of uninitialized variables being
> garbage and resulting in non-deterministic behavior. And it solves it
> in more places than the Java and C# solution does, because it deals
> with stuff like initializing all of the elements in an array when it's
> first allocated, which they don't AFAIK.
> 
> True, init doesn't make it so that programmers always remember to
> initialize all of their variables, and with a default-initialized
> variable, you have the ambiguity of whether the programmer meant to
> use the default or whether they forgot to initialize the variable, but
> that's minor in comparison to uniitialized variables being garbage
> values. And since there's nothing to stop a programmer from
> initializing a variable with an incorrect value, the fact that a
> variable is directly initialized by the programmer in Java and C#
> doesn't necessarily solve that problem any better anyway. And then
> there's also the irritation of the occasional forced initialization,
> because the compiler's flow analysis isn't good enough to detect that
> it's unecessary.
[...]

Hold on a second here, I thought the original complaint was that
*unused* local variables should generate a warning? What has that got to
do with .init? If I write code like this:

	void func() {
		int x;
		int y;

		return y+10;
	}

Then x is unused, regardless of whether the language defaults its value
to .init or not.

I can understand why Walter doesn't care to implement the necessary flow
analysis to catch these sorts of problems, but it shouldn't be confused
with variable initialization, because they are orthogonal issues. I
mean, the above code could just as easily be written:

	void func() {
		int x = 123;
		int y;
		return y+10;
	}

and x is *still* an unused variable (in the sense that the code doesn't
do anything with it after assigning an initial value).


T

-- 
"You are a very disagreeable person." "NO."