int nan

[Nick Sabalausky]

"Michiel Helvensteijn" <m.helvensteijn.remove at gmail.com> wrote in message 
news:h2810s$hl1$1 at digitalmars.com...
> Nick Sabalausky wrote:
>
>>> 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".
>
> Better than a flipflop between "runs correctly" and "runs incorrectly",
> wouldn't you agree? But of course, you're arguing on the other end of the
> spectrum. Read on.
>
>>> 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);
>>> }
>>> ------------
>
> I wouldn't call the "holy grail" overly conservative in this instance. The
> post-condition of 'foo' would simply be (1 <= returnValue <= 10). With no
> more information than that, the compiler would have to give an error,
> since 'foo' *may return a value* that results in an uninitialized read
> of 'i'. That's how it should work. No errors if and only if there is no
> possible execution path that results in failure, be it uninitialized-read
> failure, null-dereference failure or divide-by-zero failure.
>
>>> So, we only have two initial choices:
>>> - Overly conservative (C#-style or "holy grail")
>>> - Overly permissive (current D approach)
>
> I tend to agree with BCS that the programmer should have the last say,
> unless the compiler can absolutely prove that (s)he is wrong. Given the
> choice between overly conservative and overly permissive, I would pick
> overly permissive.
>
> But the beauty of the holy grail is that it's neither.
>
>> Additionally, in the C# approach (and this is speaking from personal
>> experience), anytime you do come across a provably-correct case that the
>> compiler rejects, not only is it always obvious to see why the compiler
>> rejected it, but it's also trivially easy to fix. So in practice, it's
>> really not much of a "baby with the bathwater" situation at all.
>
> But what would the fix be in the case of our example? Surely you're not
> suggesting initializing 'i' to 0? Then we'd be back in the old situation
> where we might get unexpected runtime behavior if we were wrong
> about 'foo'.
>

The fix would be one of the following, depending on what the code is 
actually doing:

---------------
// Instead of knee-jerking i to 0, we default init it to
// whatever safe value we want it to be if the loop
// doesn't set it. This, of course, may or may not
// be zero, depending on the code, but regardless,
// there are times when this IS perfectly safe.

int i = contextDependentInitVal;
for(int j = foo(); j > 3; j--) i = j;
auto k = i;
---------------

---------------
int i;
bool isSet = false; // making i nullable would be better
for(int j = foo(); j > 3; j--) {
    i = j;
    isSet = true;
}
if(isSet) {
    auto k = i;
} else { /* handle the problem */ }
---------------

Also, keep in mind that while, under this mechanism, it is certainly 
possible for a coder to cause bugs by always knee-jerking the value to zero 
whenever the compiler complains, that's also a possibility under the "holy 
grail" approach.