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