floating point verification using is?

[Don]

Steven Schveighoffer wrote:
> 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?

The thing is, if you've written something to a memory location, it's not 
uninitialized any more.

>>> 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'.

I think we could get the behaviour you want by changing the definition 
of T.init. I think it should ALWAYS be a bug to read an uninitialized 
variable; but it should be OK to have:
T x = T.init;
if (x == T.init) ...

Otherwise, there's no point in making T.init available.