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.
