Let me bring up an old chestnut topic: default initial values.

My beef with the current treatment of initial values is that some initial values (like integer and pointer types) are very convenient and some are very inconvenient (like char and floating point types). Walter has stated that if there existed an inconvenient integer or pointer value he would use that (I hope I remembered that correctly). But in practice the convenience of the initial values can be crucial. I almost never see code that explicitly initializes integers to 0 or pointers to null. For example the word count example at the bottom of the associative array example uses the statement dictionary[word]++; to both insert the word in the array if it wasn't present and increment its word count. I noticed that statement when thinking about the associative array indexing behavior but I'd like to use it now as an example of how people (including Walter himself) use initial values for their convenience. D is harder to use when some types have convenient intial values and some don't. Let's aim for consistency and just make all initial values convenient. Does anyone know of another language that has nan as the default floating point value? While I'm at it the char types initial values should IMO go back to 0, too.

As an aside, if you allocate an array of double[] or char[] the array is initially filled with 0's.

-Ben

> As an aside, if you allocate an array of double[] or char[] the array is initially filled with 0's.

I can see it now.

"DMD 0.119 release!  Bugs fixed: double[] and char[] arrays are now initialized to nan and 0xffff, respectively."

;)

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:d1a507$22h8$1@digitaldaemon.com...
>> As an aside, if you allocate an array of double[] or char[] the array is initially filled with 0's.
>
> I can see it now.
>
> "DMD 0.119 release!  Bugs fixed: double[] and char[] arrays are now initialized to nan and 0xffff, respectively."

actually that is a bug in dmd since the spec says dynamic arrays are filled with the default value when resized.

Ben Hinkle wrote:

>>"DMD 0.119 release!  Bugs fixed: double[] and char[] arrays are now initialized to nan and 0xffff, respectively."
> 
> actually that is a bug in dmd since the spec says dynamic arrays are filled with the default value when resized. 

There is a similar bug with the autocreated value of missing AA keys...

I guess just uses calloc, and "forgets" to set the proper .init values?

--anders

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d1a5mt$235t$1@digitaldaemon.com...
> actually that is a bug in dmd since the spec says dynamic arrays are filled with the default value when resized.

Oh.

..

Ben Hinkle wrote:

> My beef with the current treatment of initial values is that some initial values (like integer and pointer types) are very convenient and some are very inconvenient (like char and floating point types). Walter has stated that if there existed an inconvenient integer or pointer value he would use that (I hope I remembered that correctly).

http://www.digitalmars.com/d/function.html says:
> Local Variables
> It is an error to use a local variable without first assigning it a
> value. The implementation may not always be able to detect these cases.
> Other language compilers sometimes issue a warning for this, but since
> it is always a bug, it should be an error.

Note that this only talks about local variables. Class fields are always
initialized to the .init values (arrays *should* be, but it is buggy...)


It sounds a bit strange that the default values of all such fields,
that are being automatically initialized, should be as inconvenient
as possible ? (for local vars, it would make sense since those are
illegal anyway and might as well have such "sentinel" default values)

Not to give Walter any ideas, but -1 is a pretty inconvenient value...
Imagine if all integers and pointers started with that default! Ouch.
It would make more sense to give all types convenient values instead ?
(i.e. make them *all* zero, as in: 0 or 0.0 or false or null or '\0')


That is: change characters and floats, instead of integers and pointers?
(but this has probably *also* been beaten to death already, on this NG?)


> Does anyone know of another language that has nan as the default floating point value?

No, but D floating point support aims to be... different. :-)
(just take a look at x!<>=y, which I haven't seen elsewhere?)

> While I'm at it the char types initial values should IMO go back to 0, too.

That would make D closer to what I am used to, too:
http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html#96595

Let's just hope this does not end up making the default value
for integers and pointers unusable too... That would be sad...

Like when the default string points to 0xDEADBEEF and is -1 long :-P

--anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:d1c7ch$157m$1@digitaldaemon.com...
> Ben Hinkle wrote:
>
>> My beef with the current treatment of initial values is that some initial values (like integer and pointer types) are very convenient and some are very inconvenient (like char and floating point types). Walter has stated that if there existed an inconvenient integer or pointer value he would use that (I hope I remembered that correctly).
>
> http://www.digitalmars.com/d/function.html says:
>> Local Variables
>> It is an error to use a local variable without first assigning it a
>> value. The implementation may not always be able to detect these cases.
>> Other language compilers sometimes issue a warning for this, but since
>> it is always a bug, it should be an error.

Wow - it also says unused variables are an error. Is the doc out of date? DMD doesn't complain if I use an implicitly-initialize variable or declare an unsed variable. Not even a warning. If the doc is right I urge Walter to fix the compiler to enforce the error so that we have time to update our code. Given a choice I prefer the current compiler behavior - allow people to use defaults and be sloppy with declarations (though perhaps warn). If there is a strong reason for it (eg, it enables better optimizations, etc) then erroring is fine.

> Note that this only talks about local variables. Class fields are always initialized to the .init values (arrays *should* be, but it is buggy...)
>
> It sounds a bit strange that the default values of all such fields, that are being automatically initialized, should be as inconvenient as possible ? (for local vars, it would make sense since those are illegal anyway and might as well have such "sentinel" default values)
>
> Not to give Walter any ideas, but -1 is a pretty inconvenient value... Imagine if all integers and pointers started with that default! Ouch. It would make more sense to give all types convenient values instead ? (i.e. make them *all* zero, as in: 0 or 0.0 or false or null or '\0')

agreed.

> That is: change characters and floats, instead of integers and pointers? (but this has probably *also* been beaten to death already, on this NG?)

yeah - but it's been a while :-)

>> Does anyone know of another language that has nan as the default floating point value?
>
> No, but D floating point support aims to be... different. :-)
> (just take a look at x!<>=y, which I haven't seen elsewhere?)

But at least that is additional behavior that other languages don't have. One can safely ignore those extra features. Default values exist in other languages and it gets annoying that D's are different.

>> While I'm at it the char types initial values should IMO go back to 0, too.
>
> That would make D closer to what I am used to, too: http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html#96595

That's what I have in mind, too.

> Let's just hope this does not end up making the default value for integers and pointers unusable too... That would be sad...

All I'm asking for is consistency - either all unusable or all usable. With a preference for making them usable.

> Like when the default string points to 0xDEADBEEF and is -1 long :-P

hehe.

Ben Hinkle wrote:

> Wow - it also says unused variables are an error. Is the doc out of date?

You must be new here :-) (just kidding, but a lot of D docs are old...?)

>>That is: change characters and floats, instead of integers and pointers?
>>(but this has probably *also* been beaten to death already, on this NG?)
> 
> yeah - but it's been a while :-)

As in "we haven't had a good fight in a while". Or as in it has changed?

> All I'm asking for is consistency - either all unusable or all usable. With a preference for making them usable.

Consistency seems to be a big deal lately :-) Not sure we're getting it.

--anders

In article <d1cb3k$19ic$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>Ben Hinkle wrote:
>
>> Wow - it also says unused variables are an error. Is the doc out of date?
>
>You must be new here :-) (just kidding, but a lot of D docs are old...?)

heh. you're right - I shouldn't have been surprised.

>>>That is: change characters and floats, instead of integers and pointers? (but this has probably *also* been beaten to death already, on this NG?)
>> 
>> yeah - but it's been a while :-)
>
>As in "we haven't had a good fight in a while". Or as in it has changed?

As in "it has been a while since it was last discussed and given the people reading the list have changed and Walter is winding down on 1.0 it would be worth revisiting to make sure the right thing happens". If all that happens is the doc is fixed and the compiler bugs are fixed with dynamic arrays then that would be better than nothing.

>> All I'm asking for is consistency - either all unusable or all usable. With a preference for making them usable.
>
>Consistency seems to be a big deal lately :-) Not sure we're getting it.

Please don't lump this in with length, if that is what you mean. :-P
The two are unrelated - mostly w.r.t the scope of the issue. The $length and
friends were about a consitent syntax for some pretty different concepts - some
of which already existed in C and some not. That makes life much more
complicated. Consistency within a single concept (default values) feels to me
like a different argument than the length consistency argument.

> actually that is a bug in dmd since the spec says dynamic arrays are filled with the default value when resized.

I don't know if I like the idea of needlessly initializing large arrays to unusable values.  Wouldn't this have a significant adverse effect on performance?  Perhaps this could be a compiler option.

-Craig