Docs: Section on local variables

[Nick Sabalausky]

"Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message 
news:mailman.2003.1334971962.4860.digitalmars-d at puremagic.com...
> On Saturday, April 21, 2012 02:54:25 Jakob Ovrum wrote:
>> On Friday, 20 April 2012 at 18:40:46 UTC, Jonathan M Davis wrote:
>> > But there's no way that the compiler is going to enforce
>> > that, and if it did, it would require that you initialize the
>> > variable in the
>> > above example even though the compiler already does.
>>
>> Why can't the compiler enforce it? C# and Java compilers can do
>> it just fine.
>
> 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!".