int nan

[Nick Sabalausky]

"Nick Sabalausky" <a at a.a> wrote in message 
news:h2623m$73u$1 at digitalmars.com...
> "Michiel Helvensteijn" <m.helvensteijn.remove at gmail.com> wrote in message 
> news:h25fbk$28mg$1 at digitalmars.com...
>> Denis Koroskin wrote:
>>
>>>> int i;
>>>>
>>>> for(int j = foo(); j > 0; j--) i = bar(j);   // what if foo() returns
>>>> -5?
>>>
>>> This code doesn't compile in C# and fails with the following error at
>>> first attempt to use 'i':
>>>
>>> error CS0165: Use of unassigned local variable 'i'
>>
>> Ah, so C# is overly conservative. That's another option, of course.
>>
>> It has the advantage of always knowing at compile time that you're not
>> reading an uninitialized value. The disadvantage is that C# will often
>> throw out the baby with the bath water. The example program may be
>> perfectly valid if 'foo' always returns positive.
>>
>
> Yes, this approach is what I was getting at. In fact, I would (and already 
> have in the past) argue that this is *better* than the "holy grail" 
> approach, because because it's based on very simple and easy to remember 
> rules. Conversely, the "holy grail" approach leads to difficult-to-predict 
> cases of small, seemingly-innocent changes in one place causing some other 
> code to suddenly switch back and forth between "compiles" and "doesn't 
> compile". Take this modified version of your example:
>
> ------------
> // Imagine foo resides in a completely different package
> int foo() { return 5; }
>
> int i;
> for(int j = foo(); j > 3; j--) i = j;
> auto k = i;  // Compiles at the moment...
> ------------
>
> Now make a perfectly acceptable-looking change to foo:
> ------------
> int foo() { return 2; }
> ------------
>
> And all of a sudden non-local code starts flip-flopping between "compiles" 
> and "doesn't compile".
>
> Additionally, even the "holy grail" approach still has to reduce itself to 
> being overly conservative in certain cases anyway:
> ------------
> int foo()
> {
>    auto rnd = new RandomGenerator();
>    rnd.seed(systemClock);
>    return rnd.fromRange(1,10);
> }
> ------------
>
> So, we only have two initial choices:
> - Overly conservative (C#-style or "holy grail")
> - Overly permissive (current D approach)
>
> And if we choose "overly conservative", then our next choice is:
> - Overly conservative with simple, easy-to-use rules (C#-style)
> - Overly conservative with complex rules that have seemingly-random 
> non-localized effects ("holy grail")
>

Additionally, in the C# approach (and this is speaking from personal 
experience), anytime you do come across a provably-correct case that the 
compiler rejects, not only is it always obvious to see why the compiler 
rejected it, but it's also trivially easy to fix. So in practice, it's 
really not much of a "baby with the bathwater" situation at all.