void blah(out bool a = false){
 // blah blah blah
}

compile time use of blah results in error.

Am I doing anything wrong?

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.

If you want to ensure a is false at the beginning of the function do:

void blah(out bool a)
{
  a = false;
  // blah blah blah
}

-Steve

Steven Schveighoffer escribió:
> 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.
> 
> If you want to ensure a is false at the beginning of the function do:
> 
> void blah(out bool a)
> {
>   a = false;
>   // blah blah blah
> }
> 
> -Steve

Or just not write it, because "out" automatically initializes the value of the variable to it's default one, in the case of bool it's false.

On Sun, Aug 30, 2009 at 12:24 AM, Ary Borenszweig<ary@esperanto.org.ar> wrote:
> Steven Schveighoffer escribió:
>>
>> 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.
>>
>> If you want to ensure a is false at the beginning of the function do:
>>
>> void blah(out bool a)
>> {
>>  a = false;
>>  // blah blah blah
>> }
>>
>> -Steve
>
> Or just not write it, because "out" automatically initializes the value of the variable to it's default one, in the case of bool it's false.

Although teeeeeeechnically speaking that would be illegal code. The D spec says that it's not legal to use the value of uninitialized variables. Default initialization is kind of a poor man's substitute for actual flow control which determines that. By relying on default initialization, you're relying on what is actually nonconformant behavior, and it could be broken in the future or by a smarter compiler.

But we're getting really technical here ;)

Jarrett Billingsley wrote:
> Although teeeeeeechnically speaking that would be illegal code. The D spec says that it's not legal to use the value of uninitialized variables. Default initialization is kind of a poor man's substitute for actual flow control which determines that. By relying on default initialization, you're relying on what is actually nonconformant behavior, and it could be broken in the future or by a smarter compiler.

No.  This is an uninitialized variable in D:

  int i = void;

This is an initialized variable in D:

  int i;

A default-initialized variable is not in any way less initialized than any other initialized variable.

Flow control can add two things to D.  It can turn this:

  int i = <value>;

or, equivalently, this:

  int i;

into this:

  int i = void;

whenever it is safe to do so.  It can also turn this:

  int i = void;

into an error message if it can prove that this is /not/ safe.

It cannot ever alter the behavior of the following perfectly legal D function:

  int get_zero() {
    int i;
    return i;
  }


-- 
Rainer Deyke - rainerd@eldwood.com

Jarrett Billingsley wrote:
> On Sun, Aug 30, 2009 at 12:24 AM, Ary Borenszweig<ary@esperanto.org.ar> wrote:
>> Steven Schveighoffer escribió:
>>> 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.
>>>
>>> If you want to ensure a is false at the beginning of the function do:
>>>
>>> void blah(out bool a)
>>> {
>>>  a = false;
>>>  // blah blah blah
>>> }
>>>
>>> -Steve
>> Or just not write it, because "out" automatically initializes the value of
>> the variable to it's default one, in the case of bool it's false.
> 
> Although teeeeeeechnically speaking that would be illegal code. The D
> spec says that it's not legal to use the value of uninitialized
> variables. Default initialization is kind of a poor man's substitute
> for actual flow control which determines that. By relying on default

Am I the only one, who likes the current behaviour, and finds it annoying to be forced by the compiler to initialize all variables?

> initialization, you're relying on what is actually nonconformant
> behavior, and it could be broken in the future or by a smarter
> compiler.

How is this nonconformant? Initialization is guaranteed by D.

> But we're getting really technical here ;)

On Sun, Aug 30, 2009 at 5:34 AM, Rainer Deyke<rainerd@eldwood.com> wrote:
> Jarrett Billingsley wrote:
>> Although teeeeeeechnically speaking that would be illegal code. The D spec says that it's not legal to use the value of uninitialized variables. Default initialization is kind of a poor man's substitute for actual flow control which determines that. By relying on default initialization, you're relying on what is actually nonconformant behavior, and it could be broken in the future or by a smarter compiler.
>
> No.  This is an uninitialized variable in D:
>
>  int i = void;
>
> This is an initialized variable in D:
>
>  int i;
>
> A default-initialized variable is not in any way less initialized than any other initialized variable.

"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

I wouldn't be surprised if W himself has forgotten about this rule, since other parts of the spec make no mention of it, or seem to depend on the default-initialization of variables.

"If the Initializer is void, however, the variable is not initialized.
If its value is used before it is set, undefined program behavior will
result."
http://www.digitalmars.com/d/1.0/declaration.html

But wait.. the previous statement said that it was an error to use a
local without first assigning it a value. Meaning the code snippet
given there (int x = void; writefln(x);) is invalid.

> It cannot ever alter the behavior of the following perfectly legal D function:
>
>  int get_zero() {
>    int i;
>    return i;
>  }

I interpret the first statement as saying that this isn't, and never has been, legal D, and that DMD simply has never checked for it. It's also illegal to declare variables that are never used, but you don't get an error for that either.

As so many things in the D spec, this is unclear. The current behavior might actually be conformant to the first statement; it's just that the default initialization has made it all but pointless. The section(s) on default initialization of course do not mention how it interacts with the first rule. (Similar to how bools can't have any silly things like arithmetic operations performed on them (good!) but can be implicitly cast to almost every other basic type, meaning you can do it anyway (bad!).)

On Sun, Aug 30, 2009 at 7:13 AM, grauzone<none@example.net> wrote:
>> Although teeeeeeechnically speaking that would be illegal code. The D spec says that it's not legal to use the value of uninitialized variables. Default initialization is kind of a poor man's substitute for actual flow control which determines that. By relying on default
>
> Am I the only one, who likes the current behaviour, and finds it annoying to be forced by the compiler to initialize all variables?

The default initialization in D certainly hasn't helped me catch any bugs, only made them harder to spot. I'm a very big proponent of catching things at compile time.

>> initialization, you're relying on what is actually nonconformant behavior, and it could be broken in the future or by a smarter compiler.
>
> How is this nonconformant? Initialization is guaranteed by D.

This is where the spec is unclear, since why bother having the "can't access variables before assignment" rule if the "all variables are default-initialized" rule all but removes the need for it?

> I wouldn't be surprised if W himself has forgotten about this rule,
> since other parts of the spec make no mention of it, or seem to depend
> on the default-initialization of variables.
> 
> "If the Initializer is void, however, the variable is not initialized.
> If its value is used before it is set, undefined program behavior will
> result."
> http://www.digitalmars.com/d/1.0/declaration.html

And below that, there's even an example with local variables.

I think what you were referring to is an outdated part of the specification, especially because "= void;" was added only recently.

(Which also shows how worthless the specification is: not only incomplete, but full or inconsistencies and errors?)

As to whether initializing variables by default or disallowing reading uninitialized values is better: I think it's very annoying, if the compiler tries to be smart, but then comes in to your way. Additionally, the result of the uninitialized value detection might end up being compiler specific, and that wouldn't be beautiful at all anymore. Actually, that case is very likely, since Walter would never rigorously define how exactly it should be done.

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?