Docs: Section on local variables

[Jakob Ovrum]

On Saturday, 21 April 2012 at 11:37:29 UTC, Nick Sabalausky wrote:
> 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).

I agree, it's much easier to spot an incorrect explicit 
initializer than code unintentionally relying on an implicit 
default-initializer.

> 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#.

I've used C# a fair bit too, and this has never even happened to 
me (not in Java either using Eclipse). Of course, this is just a 
personal anecdote, but if anyone has had problems with the CFG 
approach in these languages, I'd like to hear more about it. As 
it stands the claim that people would be tossing in half-assed 
explicit initializers all the time is simply not the reality. 
Even if the compiler gets it wrong once in a blue moon, I would 
happily trade that for the massive benefits it gives you in 
writing readable, maintainable code.

I don't think this ship has sailed for D. If it were to be 
implemented, you could easily transition into it slowly like 
@property. Also, the same implementation could be used to solve 
the problem of statically checking when const/immutable 
constructors are cooked/baked, which remains an unsolved problem.