int nan

[BCS]

Hello Nick,

> "Michiel Helvensteijn" <m.helvensteijn.remove at gmail.com> wrote in
> message news:h25fbk$28mg$1 at digitalmars.com...
> 
>> 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!