On Saturday, 14 April 2012 at 06:43:11 UTC, Manfred Nowak wrote:
> F i L wrote:
>
>> It sounds like circular reasoning.
>
> Several considerations pressed the design into the current form:
> 1) always changing output on unchanged input is hard to debug
> 2) GC needs to be saved from garbage, that looks like pointers
> 3) missed explicit initializations should not create syntax errors
> 4) use hardware signalling to overcome some of the limitations
> impressed by 3).
> 5) more???
>
> For me the only questionable point is numer three.
>
> -manfred

1) Good argument.
2) Don't know enough about the GC. Can't comment.
3) I agree. I just disagree with how they are expected to be used without explicit definition.
4) I have no idea what you just said... :)
5) profit??

On Saturday, 14 April 2012 at 06:29:40 UTC, Ali Çehreli wrote:
> On 04/13/2012 09:00 PM, F i L wrote:
>
> > default is NaN
>
> Just to complete the picture, character types have invalid initial values as well: 0xFF, 0xFFFF, and 0x0000FFFF for char, wchar, and dchar, respectively.
>
> Ali

That's interesting, but what effect does appending an invalid char to a valid one have? Does the resulting string end up being "NaS" (Not a String)? Cause if not, I'm not sure that's a fair comparison.

On Saturday, April 14, 2012 09:45:57 F i L wrote:
> If D doesn't accommodate entering Laymen, how does it expect to gain popularity in any major way? Efficiency puts D on the map, convenience is what brings the tourists.

I believe that you are the first person that I have ever heard complain that D tries to default to error values. I think that some have asked why the types default to what they default to, but it's not something that people normally complain about. I've explained the reasoning behind it. You can like it or not, but as far as I can tell, this is a complete non-issue.

- Jonathan M Davis

On Saturday, April 14, 2012 09:58:42 F i L wrote:
> On Saturday, 14 April 2012 at 06:29:40 UTC, Ali Çehreli wrote:
> > On 04/13/2012 09:00 PM, F i L wrote:
> > > default is NaN
> > 
> > Just to complete the picture, character types have invalid initial values as well: 0xFF, 0xFFFF, and 0x0000FFFF for char, wchar, and dchar, respectively.
> > 
> > Ali
> 
> That's interesting, but what effect does appending an invalid char to a valid one have? Does the resulting string end up being "NaS" (Not a String)? Cause if not, I'm not sure that's a fair comparison.

You can't append a char to a char. You can append them to strings, but not each other.

Appending an invalid char results in a string with an invalid char. It won't blow up on its own. But any function which attempts to decode the string (which includes the vast majority of functions which would be called on a string) would result in a UTFException. So, you'll generally know that you have a bad string very quickly.

- Jonathan M Davis

On Saturday, 14 April 2012 at 07:59:25 UTC, Jonathan M Davis wrote:
> On Saturday, April 14, 2012 09:45:57 F i L wrote:
>> If D doesn't accommodate entering Laymen, how does it expect to
>> gain popularity in any major way? Efficiency puts D on the map,
>> convenience is what brings the tourists.
>
> I believe that you are the first person that I have ever heard complain that D
> tries to default to error values. I think that some have asked why the types
> default to what they default to, but it's not something that people normally
> complain about. I've explained the reasoning behind it. You can like it or
> not, but as far as I can tell, this is a complete non-issue.

Well my testimonial evidence against yours, eh? :) I'm not trying to get under anyone's skin here. You've explained the logic behind the decision and I think I've made some valid points against that logic. You obviously don't feel like arguing the point further, so I'll just leave it at that.

On Saturday, 14 April 2012 at 07:52:51 UTC, F i L wrote:
> On Saturday, 14 April 2012 at 06:43:11 UTC, Manfred Nowak wrote:
>> F i L wrote:
>>
>> 4) use hardware signalling to overcome some of the limitations
>> impressed by 3).
>
> 4) I have no idea what you just said... :)

On Saturday, 14 April 2012 at 07:58:44 UTC, F i L wrote:
> That's interesting, but what effect does appending an invalid char to a valid one have? Does the resulting string end up being "NaS" (Not a String)? Cause if not, I'm not sure that's a fair comparison.

The initialization values chosen are also determined by the underlying hardware implementation of the type. Signalling NANs (http://en.wikipedia.org/wiki/NaN#Signaling_NaN) can be used with floats because they are implemented by the CPU, but in the case of integers or strings their aren't really equivalent values.

On Saturday, 14 April 2012 at 07:45:58 UTC, F i L wrote:
> My original post was inspired by me showing my D code to another C# guy earlier, and coming up with poor explanations as to why floats where required to be defaulted in my math lib. His reaction what along the lines of my first post.

I think the correct mindset when working in D is to think that "all variables should be initialized" and if you get incorrect calculations with zero values, division by zero errors or nan errors the most likely mistake is often that this guideline was not followed.

Am 14.04.2012 07:48, schrieb F i L:
> On Saturday, 14 April 2012 at 05:19:38 UTC, dennis luehring wrote:
>>  Am 14.04.2012 06:00, schrieb F i L:
>>>       struct Foo {
>>>         int x, y;    // ready for use.
>>>         float z, w;  // messes things up.
>>>         float r = 0; // almost always...
>>>       }
>>
>>  how often in your code is 0 or 0.0 the real starting point?
>>  i can't think of any situation except counters or something
>>  where 0 is a proper start - and float 0.0 is in very very few
>>  cases a normal start - so whats your point?
>
> Every place that a structure property is designed to be mutated
> externally. Almost all Math structures, for instance.

if a float or double is initalized with nan - all operations on them will result to nan - that is a very good sign for missing "proper" initialisation

what does make float default to 0.0 better - does it just feel better?

On 14/04/12 09:45, F i L wrote:
> Jonathan M Davis wrote:
>> No. You always have a bug if you don't initialize a variable to the value that
>> it's supposed to be. It doesn't matter whether it's 0, NaN, 527.1209823, or
>> whatever. All having a default value that you're more likely to use means is
>> that you're less likely to have to explicitly initialize the variable. It has
>> to be initialized to the correct value regardless.
>
> Yes, I'm in favor of default values. That's not my argument here. I'm saying it makes more sense to have the default values be _usable_ (for convenience) rather than designed to catch (**cause**) bugs.
>

Why would a compiler set `real' to 0.0 rather then 1.0, Pi, .... ?
The more convenient default set certainly depends on the underlying mathematics,
and a compiler  cannot (yet) understand the encoded mathematics.
NaN is certainly the certainly the very choice as whatever the involved mathematics,
they will blow up sooner or later. And, from a practical point of view, blowing up
is easy to trace.

>

F i L:

> So basically, it's for debugging?

To avoid bugs it's useful for all variables to be initialized before use (maybe with an explicit annotation for the uncommon cases where you want to use uninitialized memory, like: http://research.swtch.com/sparse ). Having a variable not initialized is a common source of bugs.

C# solves this requiring explicit initialization all variables before use. Walter doesn't believe that flow analysis is flexible enough in a system language like D (or he doesn't want to implement it) so he has not used this idea in D.

So D uses a different worse strategy, it initializes the variables to something unusable, so if you try to use them, your program fails clearly.

The idea of setting the variables to something useful, like setting initialized chars to 'a' and floating point values to 0.0 looks handy, but on the long run it's not an improvement. You sometimes don't initialize a char variable because you are fine for it to be 'a', and some other times you don't set it just because you forget to initialize it. The compiler can't tell apart the two cases, and this is may be a bug in your code.

In practice I think having FP variables initialized to NaN has not avoided me significant bugs in the last years. On the other hand I have ported some C code that uses global floating point arrays/variables to D, and I have had to remove some bugs caused by the assumption in the C code that those global FP variables are initialized to zero, that's false in D.

Another source of troubles is large fixed-sized FP global arrays, that inflate the binary a *lot*. You have to remember to initialize them to zero explicitly:

double[100_000] foo; // bad, inflates binary.
double[100_000] bar = 0.0; // good.
void main() {}

In D I'd like the solution used by C# + an annotation to not initialize a variable or array.

Bye,
bearophile

On 4/14/12, bearophile <bearophileHUGS@lycos.com> wrote:
> Having a variable not initialized is a common source of bugs.

I'm going to argue that this was true for C/C++ but is much less true for D. One benefit of having integrals initialized to 0 is that you now have a defined default that you can rely on (just as you can rely on pointers being null by default). Personally I find this to be a big win in productivity. If the language/runtime does something defined for me then I can focus on more important things.

But NaN might be a good thing for all I know.. I rarely use floating-point so I'll stay out of that, but I'd like to have this fixed: http://d.puremagic.com/issues/show_bug.cgi?id=6303