int nan

[Nick Sabalausky]

"Nick Sabalausky" <a at a.a> wrote in message 
news:h28gqc$1duk$1 at digitalmars.com...
> "Michiel Helvensteijn" <m.helvensteijn.remove at gmail.com> wrote in message 
> news:h2810s$hl1$1 at digitalmars.com...
>>
>>> 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.
>

I would also be perfectly ok with this compiling:

---------------
int foo()
out
{
    assert(ret >= 5 && ret <= 10);
}
body
{
    auto rnd = new RandomGenerator();
    rnd.seed(systemClock);
    int ret = rnd.fromRange(5,10);
    return ret;
}

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

---------------

Ie, I can agree that the compiler should be able to take advantage of a 
function's contract when determining whether or not to throw a "may not get 
inited" error, but I strongly disagree that the contract used should be 
implicity defined by the actual behavior of the function.

IMO, In the sans-"out" versions of foo, the *only* post-condition contract 
is that it returns an int. If foo's creater really does intend for foo's 
result to always be within a certain subset of that, no matter what 
revisions are eventually made to foo (without actually changing the whole 
purpose of foo), then that should be put in a formal post-condition contract 
anyway, such as above.