Docs: Section on local variables

[Nick Sabalausky]

"Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message 
news:mailman.2009.1334999769.4860.digitalmars-d at puremagic.com...
> 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...
>>
>> > 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!".
>
> 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.
>
> So, it's highly debatable whether Java and C#'s solution would be an
> improvement over init or whether having it in addition to init would be
> desirable, but regardless of whether either solves the issue of 
> programmers
> not initializing variables to correct values, init definitely solves the
> problem of having garbage for uninitialized variables like you do in 
> C/C++.
> And _that_ is what _needs_ to be solved.
>

"And _that_ is what _needs_ to be solved." <--- Strawman.

The garbage values issue is nothing more than C/C++ going a stupid route. 
It's not a problem to be solved - it's merely a C/C++ "WAT" that is to 
simply *not be imitated*. Every other (relevent) language in existance (as 
far as I'm aware) avoids copying that broken design.

Score: C/C++: Zero. Everything else: One.

You can frame that as "a problem to be solved", fine. But there it is. It's 
solved. In both D and C# and everywhere but C/C++. Done. End of *that* 
story.

But now, C#, as well as some other langauges, *also* have guards against 
forgetting to initialize a variable to it's *intended* initial value. D does 
*not* guard against this, period.

C/C++: Fails to solve A and B: Big fat Zero
D: Solves A, fails to solve B: One
C#: Solves A and B: Two

D's .init doesn't even enter into this. D's .init doesn't solve a damn thing 
here. It solved the *other* problem - it's not relevent to *this* problem. 
C# has solved an *additional* issue *beyond* what D (and everything else) 
solves. You make it sound like .init is a "different but equal" approach. It 
isn't. It solves one problem, whereas C# solves two.

As far as "there's nothing to stop a programmer from initializing a variable 
with an incorrect value": that's a poor argument. Failing to give an initial 
value in all code paths is a bigger danger (ie, more likely) than using the 
wrong value. That's because if you're initializing it *at all*, you're 
already *at least* thinking about it, which gives you a huge advantage. On 
top of that, while explicitly initing to the wrong value isn't catchable by 
the compiler anyway, failing to explicitly init at all *is* catchable (which 
therefore *forces* the programmer to put at least *some* thought into it, 
thus *decreasing* the likelyhood of the wrong value as compared to D).

Furthermore, Walter has argued that people would just toss values in to shut 
it up whithout any regard to whether or not it's right. Fact is, in real 
world practice, and this is coming from someone who has actually *used* C#, 
and not merely speculated about it: that's *not* what typically happens in 
real-world C#.

But again, I know D's never going to change in this regard, and I can even 
live with that. But it *is*, *objectively*, a downside of D versus C#. 
Disputing that with "But D gets rid of garbage initial values!" is nothing 
but an irrelevant strawman.