"Michiel Helvensteijn" <m.helvensteijn.rem...@gmail.com> wrote in message news:h25fbk$28m...@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")