floating point verification using is?

[Steven Schveighoffer]

On Mon, 28 Dec 2009 21:52:24 -0500, Don <nospam at nospam.com> wrote:

> Steven Schveighoffer wrote:
>> Whether you like it or not, the runtime must initialize it to  
>> something, even if the value means "uninitialized".
>
> The key question is: is it valid to read an uninitialized variable? I  
> would hope the compiler would flag that as an error. The use of  
> signalling NaNs was based on the assumption that you should *never* be  
> reading uninitialized variables.
>
> A consequence is that you should also NEVER read float.init!

I am not even close to a floating point expert.  In fact, I try to avoid  
them like the plague.  All I want to do is verify that the bit pattern  
being written to a memory location is the bit pattern I expect to be  
written.  How do I do that without comparing what I expect to what I wrote?

>
>> That value should always be consistent.  There has to be a way to  
>> verify that the value was set properly.  Otherwise, how do you verify  
>> things
>> like communication protocols or expectations for runtime functions?
>
> I think that sending an uninitialized variable down a communication  
> channel is always a bug.

Just wait, someone will define it :)  If I want to verify that it's any  
value *but* T.init, how do I do that?  And I don't think using <>=!@%$ to  
do it is worth the trouble.

>> It has to be a bit pattern, because all other T.init values, including  
>> those of aggregates which might contain floating points, are bit  
>> patterns.
>>
>>> Consider this code:
>>>
>>> T x;
>>> if (x==T.init) { writefln("x is uninitialized"); }
>>>
>>> Is this code valid? You are reading the value of an uninitialized  
>>> variable.
>>  Correct that to:
>>  T x;
>> if(x is T.init) {writefln("x is uninitialized"); }
>>  Then I think it is valid.  I don't care if == is hijacked away from  
>> bitwise comparison, in fact, it is necessary in many cases.  But there  
>> should be a way to do bitwise comparison for verification, and 'is'  
>> fits the bill perfectly.
>
> That does preclude a compiler from ever giving you errors/warnings about  
> using uninitialized variables. I think it's wrong.

I'm not using it in every-day code (although I don't think it's wrong to  
do so), I'm using it for asserts and unit tests.  I'm asserting that  
what's happening is what I expect is happening.  To make this unreasonably  
difficult makes no sense to me.  To say "is works on everything but  
floating point initializers" sounds ridiculously inconsistent.  Maybe  
preventing it is the Right Thing to do, but it is possible to do, so what  
harm can it cause?  It wouldn't even cause an exception.

Note that I don't think == should change behavior, just 'is'.

-Steve