Anders F Björklund wrote:
> Ivan Senji wrote:
> 
>> In that case 0 is as bad as anything else. Atleast with nan, a developer may decide to print sum to console and find out that it is nan. But what if the formula is
>> sum = sum*dx + dy; -> this will cause subtle errors if you expected sum to be 1 for example. But you will get some numbers as a result but they are wrong even though you think they are allright, and the next thing you know your D-driven spaceship is falling onto Mars too fast and you are loosing alot of money an thinking: if only that sum was initialized to nan! :)
> 
> 
> Then again, it's usually better to catch those bugs at compile time ?
> 

Compile time would be best. C# compiler does the same thing, and although it can be a little irritating it is uesfull. Maybe this could be warning? But it isn't that easy to detect.

Ivan Senji wrote:

>> Then again, it's usually better to catch those bugs at compile time ?
> 
> Compile time would be best. C# compiler does the same thing, and although it can be a little irritating it is uesfull. Maybe this could be warning? But it isn't that easy to detect.

D doesn't do warnings, so run-time errors seem to be preferred.

--anders

"Ivan Senji" <ivan.senji_REMOVE_@_THIS__gmail.com> wrote in message news:dtadui$2pt4$1@digitaldaemon.com...
> The policy of D is: initialize things to error states if possible. That unfortunatelly is imposible for int's but is for floats and chars.

That's right. The default initialization is *not* about being convenient or a shorthand. It's about being an aid to writing bug free code.

If there was a nan value for ints, that would be the default initialization for that, too. I'd love it if you could set a bit for a memory address that is cleared when the address is written to, and generates a hardware fault if it is read with that bit set. But there is no such thing, and nan is the best we can do otherwise.

Walter Bright wrote:

> That's right. The default initialization is *not* about being convenient or a shorthand. It's about being an aid to writing bug free code.

So it's an error to use ints before they're initialized ?

I thought it was "OK" to assume they all started at zero...
You know, like in: http://www.digitalmars.com/d/wc.html ;-)

> If there was a nan value for ints, that would be the default initialization for that, too. I'd love it if you could set a bit for a memory address that is cleared when the address is written to, and generates a hardware fault if it is read with that bit set. But there is no such thing, and nan is the best we can do otherwise. 

So if the int.init is ever changed to something "nan"-ish, like
-1 or 0xDEADBEEF or something, it could stop to work later on ?

Guess this means to start using an "= 0;" explicit init value.

--anders

"Dave" <Dave_member@pathlink.com> wrote in message news:dt85ll$2vis$1@digitaldaemon.com...
>
> Rational: nan will propogate through an entire calculation if the
> developer
> forgets to initialize a floating point variable.
[snip]
> Maybe I'm wrong.. Opinions?
>
> Thanks,
>
> - Dave

I'm with you that nan initializer is annoying. The archives have some
discussions on the topic - with Walter's replies. My own approach would be
to use 0 initializer, toss 'auto' and introduce that := operator that came
up recently that I talk about every now and then. The benefit of := is that
*you* supply the initialization so the whole issue of worying about the
default initializer is much less common. For example instead of
 double x;
and wondering what the initial value is (if any) one writes
 x := 0.0;
and you're done. Multiple variables are declared-and-inited using
 x := y := z := 0.0;

-Ben

ps. I hope people aren't annoyed by this plug but := is in Cx http://www.cxlang.org

Walter Bright wrote:
> I've also heard from people who do serious numerical work that, at last, D is a language that cares about numerical analysis and its needs. Default initializing to nan is part of that - it forces the user to *think* about what he wants the initial value to be. Initializing it by default to 0 means that it can easilly be overlooked, and 0.0 can introduce undetected, subtle errors in the result.
> 

I agree. I'm currently working on an involved combinatorial calculation, and having one of the doubles auto-initialized to NAN help me find a bug in one of the calculations which would have been very difficult to find otherwise.

I say keep it.


> There is a 'nan' value for pointers - null, a 'nan' value for UTF-8 chars - 0xFF - which is an illegal UTF-8 character. If there was a 'nan' value for ints, D would use it as the default, too. 
> 
> 

There *is* a way get this behavior, and it can be done at compile time: raise an error when an int is assigned an initial value which cannot be calculated at compile time. This behavior could even be turned on with a command-line switch, -nan, or whatever.

For example:

int x = 1;
int y, z;
// initialization:
y = 7; // this is obviously ok
y = x; // this would also ok
z = abs(y); // this would raise an error, requires runtime evaluation

Or, even better, raise an error when the initialization value isn't a numeric literal. This would probably be even more consistent with the floating-point NAN behavior.

John Stoneham wrote:
> Walter Bright wrote:
>> I've also heard from people who do serious numerical work that, at last, D is a language that cares about numerical analysis and its needs. Default initializing to nan is part of that - it forces the user to *think* about what he wants the initial value to be. Initializing it by default to 0 means that it can easilly be overlooked, and 0.0 can introduce undetected, subtle errors in the result.
>>
> 
> I agree. I'm currently working on an involved combinatorial calculation, and having one of the doubles auto-initialized to NAN help me find a bug in one of the calculations which would have been very difficult to find otherwise.
> 
> I say keep it.
> 
> 
>> There is a 'nan' value for pointers - null, a 'nan' value for UTF-8 chars - 0xFF - which is an illegal UTF-8 character. If there was a 'nan' value for ints, D would use it as the default, too.
>>
> 
> There *is* a way get this behavior, and it can be done at compile time: raise an error when an int is assigned an initial value which cannot be calculated at compile time. This behavior could even be turned on with a command-line switch, -nan, or whatever.

This would be nice.


Sean

"Anders F Björklund" <afb@algonet.se> wrote in message news:dtah5j$2snt$1@digitaldaemon.com...
> Walter Bright wrote:
>> That's right. The default initialization is *not* about being convenient or a shorthand. It's about being an aid to writing bug free code.
>
> So it's an error to use ints before they're initialized ?
> I thought it was "OK" to assume they all started at zero...
> You know, like in: http://www.digitalmars.com/d/wc.html ;-)

Sometimes I get lazy. :-) I'll say it's poor style, and yes, I'm guilty of it.

>> If there was a nan value for ints, that would be the default initialization for that, too. I'd love it if you could set a bit for a memory address that is cleared when the address is written to, and generates a hardware fault if it is read with that bit set. But there is no such thing, and nan is the best we can do otherwise.
>
> So if the int.init is ever changed to something "nan"-ish, like -1 or 0xDEADBEEF or something, it could stop to work later on ?

It isn't going to change, for the pragmatic reason it'll break too much code. There's too much water under that bridge.

> Guess this means to start using an "= 0;" explicit init value.

I think it's good style to let the maintainer know that one intended it to be 0.

Walter Bright wrote:

>>I thought it was "OK" to assume they all started at zero...
>>You know, like in: http://www.digitalmars.com/d/wc.html ;-)
> 
> Sometimes I get lazy. :-) I'll say it's poor style, and yes, I'm guilty of it.

As long as it is clear... (In some other languages, it's stylish)
But in D, the .init values are a debugging aid and not a shortcut.

>>Guess this means to start using an "= 0;" explicit init value.
> 
> I think it's good style to let the maintainer know that one intended it to be 0. 

Yeah, I usually do this anyway - just to avoid warnings in C:
"warning: `sum' might be used uninitialized in this function"

--anders

Sean Kelly wrote:
> John Stoneham wrote:
>> Walter Bright wrote:
>>> I've also heard from people who do serious numerical work that, at last, D is a language that cares about numerical analysis and its needs. Default initializing to nan is part of that - it forces the user to *think* about what he wants the initial value to be. Initializing it by default to 0 means that it can easilly be overlooked, and 0.0 can introduce undetected, subtle errors in the result.
>>>
>>
>> I agree. I'm currently working on an involved combinatorial calculation, and having one of the doubles auto-initialized to NAN help me find a bug in one of the calculations which would have been very difficult to find otherwise.
>>
>> I say keep it.
>>
>>
>>> There is a 'nan' value for pointers - null, a 'nan' value for UTF-8 chars - 0xFF - which is an illegal UTF-8 character. If there was a 'nan' value for ints, D would use it as the default, too.
>>>
>>
>> There *is* a way get this behavior, and it can be done at compile time: raise an error when an int is assigned an initial value which cannot be calculated at compile time. This behavior could even be turned on with a command-line switch, -nan, or whatever.
> 
> This would be nice.

I take it back:

struct S { int i; }


Sean