int nan

Nick Sabalausky a at a.a
Sat Jun 27 14:14:46 PDT 2009


"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")





More information about the Digitalmars-d mailing list