Jeremie Pelletier wrote:
Ary Borenszweig wrote:
Walter Bright wrote:
Denis Koroskin wrote:
> On Sat, 26 Sep 2009 22:30:58 +0400, Walter Bright
> <newshou...@digitalmars.com> wrote:
>> D has borrowed ideas from many different languages. The trick is to
>> take the good stuff and avoid their mistakes <g>.
>
> How about this one:
>
http://sadekdrobi.com/2008/12/22/null-references-the-billion-dollar-mistake/
>
>
> :)
I think he's wrong.
Please, please, please, do some fun little project in Java or C# and
drop the idea of initializing variables whenever you declare them.
Just leave them like this:
int i;
and then later initialize them when you need them, for example
different values depending on some conditions. Then you'll realize how
powerful is having the compiler stop variables that are not
initialized *in the context of a function, not necessarily in the same
line of their declaration*. It's always a win: you get a compile time
error, you don't have to wait to get an error at runtime.
Until you do that, you won't understand what most people are answering
to you.
But I know what you'll answer. You'll say "what about pointers?",
"what about ref parameters?", "what about out parameters?", and then
someone will say to you "C# has them", etc, etc.
No point disussing non-null variables without also having the compiler
stop uninitialized variables.
All null values are uninitialized, but not all initializers are null,
especially the void initializer.
I don't see your point here. "new Object()" is not a null intiializer
nor "1"... so?
You can't always rely on initializers
in your algorithms, you can always rely on null.
Yes, I can always rely on initializers in my algorithm. I can, if the
compiler lets me safely initialize them whenever I want, not necessarily
in the line I declare them.
Just out of curiosity: have you ever programmed in Java or C#?