Hello Nick,
"Michiel Helvensteijn" <[email protected]> wrote in
message news:[email protected]...
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".
Yes, trying to solve the problem for all cases won't work, but I think the
default should be to trust the programer. If you can show for sure with a
trivial set of rules that I use a variable before setting it give me an error.
If not, get the heck out of my way!
