null [re: spec#]

[Nick Sabalausky]

"Nick Sabalausky" <a at a.a> wrote in message 
news:ib5ht0$2uff$1 at digitalmars.com...
> "Walter Bright" <newshound2 at digitalmars.com> wrote in message 
> news:ib5bue$2ldp$1 at digitalmars.com...
>> Jonathan M Davis wrote:
>>> Going C# or Java's route forces the programmer to initialize variables 
>>> even in cases where they know that it's not necessary (which is annoying 
>>> but may or may not be worth it),
>>
>> Correct. It's not that doing flow analysis is hard, it's that it's 
>> impossible to do it correctly. So you wind up with wishy-washy messages 
>> that p "might not" be initialized, which is what the Java compiler does 
>> for this:
>>
>>   class A
>>   {
>>        public void foo()
>>        {
>>            Object p;
>>            if (m)
>>                 p = new Object();
>>            if (m)
>>                 p.toString();  // <-- p might not have been initialized
>>        }
>>        boolean m;
>>   }
>>
>> It even errors out if you write it as:
>>
>>   class A
>>   {
>>        public void foo()
>>        {
>>            Object p;
>>            if (m)
>>                 p = new Object();
>>            if (p != null)  // <-- p might not have been initialized
>>                 p.toString();
>>        }
>>        boolean m;
>>   }
>>
>> Note that the error message is on the null check!
>
> Since when should crap like that ever be written in the first place? In a 
> code review, I'd slap both of those with a giant red "convoluted" stamp, 
> *especially* if it's not just a trivial example like those.
>
> Besides, I'd much rather have easily-fixable false positives like that 
> then the false negatives D gets now:
>
> Object p;
> if (m)
>    p = new Object();
> p.toString(); // Boom!, but *only* at run-time, and *only* if m just 
> happens to be true.
>
> Plus, as I've argued before, I *wouldn't* want perfect flow analysis on 
> that, I'd rather have easily-rememberable rules. If the 
> initialization-safety of your code is dependent on complex logic, then 
> you've written it wrong anyway.
>
> In simple examples like yours above, the fixes are not only obvious, but 
> much more clear:
>
> Object p;
> if (m)
> {
>    p = new Object();
>    p.toString();
> }
>
> And in more complex cases, relying on complex logic to ensure things are 
> inited properly is just wrong anyway, as I said above. Seriously, this 
> whole "feature" amounts to nothing more than allowing the following 
> *broken* code to occasionally get overlooked...
>
> Object p;
> if (m)
>    p = new Object();
> p.toString();
>
> ...just for the completely non-existent "convenience" of writing crap like 
> this...
>
> Object p;
> if (m)
>    p = new Object();
> if (m)
>    p.toString();
>
> ...instead of just doing it right:
>
> Object p;
> if (m)
> {
>    p = new Object();
>    p.toString();
> }
>
> You can label C#-style init-checking "wishy-washy" all you want, but 
> that's still a hell of a lot better than "wrong", which is what D does (as 
> evidenced by my first example above).
>

Additionally, the root problem with default values is that they make 
deliberately-default-inited declarations and accidentally-uninited 
declarations completely indistinguishable by both the compiler and the 
programmer.

(And no, "accidentally-uninited" does *not* imply "undefined value". If 
something's supposed be inited to X and it gets inited to Y, that's still 
*wrong* - *even* if it's reproducibly-wrong.)