On Sunday, 19 August 2012 at 14:14:00 UTC, Michel Fortin wrote:
On 2012-08-19 05:54:49 +0000, Walter Bright
<newshou...@digitalmars.com> said:
On 8/18/2012 9:21 PM, Nick Sabalausky wrote:
After actually *using* both D (default-initialization) and C#
(statically/conservatively ensure things can't be accessed
without
being explicitly inited), and I'm convinced the benefits of
the static
checks easily outweigh the fear of a knee-jerk "=0".
I'm less willing to throw default initialization out - I like
it & rely on it. The C# approach pretty much ends default
initialization, including for user defined types.
I like default initialization too, and I rely on it. By that I
mean that all the time I write "size_t count;" and assume it'll
be default initialized to zero. I like it because it's less
typing and it's simple: if I don't assign anything it's zero. I
can't do that for floats or chars, because the default
initialization gives me a unusable value. In my mind C#-style
conservative flow analysis errors are better than default
initialization to a bogus value because they catch the problem
at compile time. But on the other side I'd rather not give up
on integer default initialization to zero, as I actually prefer
this over everything else.
So Walter, which default initialization do you like an rely on?
As I said, personally, I'd have everything initialized to zero
by default. But at this point you can't really change this even
if you want to: some program somewhere might rely on float
being initialized to NaN by default and might start to give
erroneous results if you change the default. (Notice the irony?)
The problem with implicit initialisation to zero is that it is
indistinguishable from simply forgetting to initialise the value.
There's three scenarios here:
1. You intentionally relied on implicit initialisation: GOOD.
2. You forgot, 0 wasn't what you wanted, but the error shows up
quickly: NOT BAD
3. You forgot, 0 wasn't what you wanted, but the error is
subtle/rare: BAD
#3 is where the nasty bugs come in. From my experience, these
bugs have the potential to be monsters, and in my opinion,
avoiding them is far more important than saving a couple of
keystrokes in initialisation.
There's two solutions:
1. Conservative compile-time error on uninitialised variables.
2. Initialise to a value that will make scenario #2 more likely
than scenario #3 (e.g. NaN)
Personally, I'd prefer option 1. Walter's argument is that this
"leads to the programmer getting annoyed with false positive
error diagnostics, and he'll likely add an =0", which is true,
but in my opinion this scenario is quite rare to start with, and
it's even more rare that 0 isn't actually the right
initialisation value, and even then it's only a problem if the
introduced bug is hard to reproduce. I find it more likely that
the NaN will go unnoticed and cause rare bugs.
