August 30, 2009
Jarrett Billingsley wrote:
> "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." http://www.digitalmars.com/d/1.0/function.html

Then the spec is wrong.  Default initialization removes the need to explicitly assign a value to a variable in order to initialize it.

The purpose of default initialization is not to find or reduce bugs, but to reduce the size of legal programs.  For the purpose of reducing bugs, it would be better to always require explicit initialization.


-- 
Rainer Deyke - rainerd@eldwood.com
August 30, 2009
On Sun, Aug 30, 2009 at 3:02 PM, Rainer Deyke<rainerd@eldwood.com> wrote:
> The purpose of default initialization is not to find or reduce bugs, but to reduce the size of legal programs.

I'm wondering where the heck you got that justification.
August 30, 2009
On Sun, Aug 30, 2009 at 3:14 PM, Jarrett Billingsley<jarrett.billingsley@gmail.com> wrote:
> On Sun, Aug 30, 2009 at 3:02 PM, Rainer Deyke<rainerd@eldwood.com> wrote:
>> The purpose of default initialization is not to find or reduce bugs, but to reduce the size of legal programs.
>
> I'm wondering where the heck you got that justification.

Also, the spec says this:

"Members are always initialized to the default initializer  for their type, which is usually 0 for integer types and NAN for floating point types. This eliminates an entire class of obscure problems that come from neglecting to initialize a member in one of the constructors." http://www.digitalmars.com/d/1.0/class.html

This suggests, to me, that default initialization _is_ - at least in Walter's mind - supposed to eliminate bugs.
August 31, 2009
Jarrett Billingsley wrote:
> On Sun, Aug 30, 2009 at 3:02 PM, Rainer Deyke<rainerd@eldwood.com> wrote:
>> The purpose of default initialization is not to find or reduce bugs, but to reduce the size of legal programs.
> 
> I'm wondering where the heck you got that justification.

By looking at the actual effect of default initialization on the
language.  Imagine D without default initialization.  This would be a
syntax error:
  int i;
Instead, you would have to write this:
  int i = 0;

Clearly this imaginary variant of D is no more error-prone than D as it actually is.  If anything, it is less error-prone, because it forces you to be explicit about how you want your variables to be initialized.  It is, however, more verbose.


-- 
Rainer Deyke - rainerd@eldwood.com
August 31, 2009
Jarrett Billingsley wrote:
> "Members are always initialized to the default initializer  for their type, which is usually 0 for integer types and NAN for floating point types. This eliminates an entire class of obscure problems that come from neglecting to initialize a member in one of the constructors." http://www.digitalmars.com/d/1.0/class.html
> 
> This suggests, to me, that default initialization _is_ - at least in Walter's mind - supposed to eliminate bugs.

You (and possibly Walter) are comparing default initialization to uninitialized variables, which is a false dichotomy.  I'm comparing default initialization to explicit initialization.


-- 
Rainer Deyke - rainerd@eldwood.com
August 31, 2009
Rainer Deyke wrote:
> Jarrett Billingsley wrote:
>> "Members are always initialized to the default initializer  for their
>> type, which is usually 0 for integer types and NAN for floating point
>> types. This eliminates an entire class of obscure problems that come
>> from neglecting to initialize a member in one of the constructors."
>> http://www.digitalmars.com/d/1.0/class.html
>>
>> This suggests, to me, that default initialization _is_ - at least in
>> Walter's mind - supposed to eliminate bugs.
> 
> You (and possibly Walter) are comparing default initialization to
> uninitialized variables, which is a false dichotomy.  I'm comparing
> default initialization to explicit initialization.

The whole point is to avoid uninitialized variables. Ideally, this would be done with explicit initialisation.
The problem is that explicit initialisation is very painful to enforce. You can, however, enforce default initialisation -- it sometimes causes inefficiency, but it doesn't hurt the programmer much. And the =void allows you to avoid the efficiency hit, for the rare occassions when it matters.

Default initialisation is a poor man's explicit initialisation.
August 31, 2009
On Sun, 30 Aug 2009 11:25:59 -0400, Ellery Newcomer <ellery-newcomer@utulsa.edu> wrote:

> Steven Schveighoffer wrote:
>> On Sat, 29 Aug 2009 20:15:55 -0400, Ellery Newcomer
>> <ellery-newcomer@utulsa.edu> wrote:
>>
>>> void blah(out bool a = false){
>>>  // blah blah blah
>>> }
>>>
>>> compile time use of blah results in error.
>>>
>>> Am I doing anything wrong?
>>
>> out implies a reference.  You can't have a reference to a manifest
>> constant like that.
>
> Are you saying a parameter like
>
> out type a = b
>
> implies the function assigns b's memory location to a?

In a parameter list?  What this does:

void foo(int i = 4);

is allow you to call foo with no arguments, and i is initialized to 4.

Now, let's say foo is written like this:

void foo(ref int i = 4);

What is i referencing when you call:

foo();

???

-Steve
August 31, 2009
Steven Schveighoffer wrote:

> What is i referencing when you call:
>   foo();

Is this an argument for making

  int j;
  void foo(ref int i = &j);
  foo():

legal D?

-manfred


August 31, 2009
On Mon, 31 Aug 2009 13:00:34 -0400, Manfred_Nowak <svv1999@hotmail.com> wrote:

> Steven Schveighoffer wrote:
>
>> What is i referencing when you call:
>>   foo();
>
> Is this an argument for making
>
>   int j;
>   void foo(ref int i = &j);
>   foo():
>
> legal D?
>

No, I'm just trying to explain why having a default value for a ref arg that is a manifest constant makes no sense.

It's possible that something like what you wrote could work (although I'd write it foo(ref int i = j)).

-Steve
August 31, 2009
On Mon, 31 Aug 2009 14:55:43 -0400, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

>
> It's possible that something like what you wrote could work (although I'd write it foo(ref int i = j)).

In fact, it does work, in D1 no less.

# cat testme.d
import tango.io.Stdout;

int j;
void foo(ref int i = j)
{
    i++;
}

void main()
{
    int i = 4;
    foo();
    foo(i);
    Stdout(i, j).newline;
}
# dmd testme.d
# ./testme
5, 1


-Steve