=?UTF-8?B?Ikx1w61z?= Marques" <luismarques gmail.com> writes:

Should this be supported?

     double[8] foo = [1.0, 2.0, void, 3.0, 3.5, void, void, void];

(it's not supported at the moment)

=?UTF-8?B?Ikx1w61z?= Marques" <luismarques gmail.com> writes:

Just to clarify, this is supported, of course:

      double[8] foo = void;
      foo[0] = 1.0;
      foo[1] = 2.0;
      foo[3] = 3.0;
      foo[4] = 3.5;

"bearophile" <bearophileHUGS lycos.com> writes:

Luís Marques:

 Should this be supported?

     double[8] foo = [1.0, 2.0, void, 3.0, 3.5, void, void, 
 void];

 (it's not supported at the moment)

I think I have not needed this so far. It looks dangerous. 
Generally D tries to initialize variables. What are your use 
cases?

Bye,
bearophile

=?UTF-8?B?Ikx1w61z?= Marques" <luismarques gmail.com> writes:

Hi bearophile.

This was just an academic question. It just seemed to me that if 
"double[8] foo = void" was deemed to warrant support, that it is 
a bit unorthogonal not to support the void in the specific 
indexes. This is just nitpicking, but I thought it might be worth 
asking, it could be that support for this was just an oversight 
or DMD limitation.

"eles" <eles eles.com> writes:

On Friday, 26 April 2013 at 14:58:35 UTC, Luís Marques wrote:
 Should this be supported?

     double[8] foo = [1.0, 2.0, void, 3.0, 3.5, void, void, 
 void];

 (it's not supported at the moment)

which reminds me about the proposal to allow declaration of 
static arrays with

double[$] foo = [1.0, 2.0, void, 3.0, 3.5, void, void, void];

which is more convenient since one discovers a counting error 
only when compiles.

Has a decision been reached for this issue?

Currently in gdc:

double[$] foo = [1.0, 2.0];

fails with

main.d:18: Error: undefined identifier __dollar

double[1] foo = [1.0, 2.0];

fails with

main.d:18: Error: array initializer has 2 elements, but array 
length is 1

but

double[4] foo = [1.0, 2.0];

is accepted, which is a bit strange (I think the compiler should 
give at least a warning if too many elements are reserved for an 
array).

=?UTF-8?B?Ikx1w61z?= Marques" <luismarques gmail.com> writes:

On Friday, 26 April 2013 at 15:45:27 UTC, eles wrote:
 which reminds me about the proposal to allow declaration of 
 static arrays with
 double[$] foo = [1.0, 2.0, void, 3.0, 3.5, void, void, void];

Seems nice.

 double[4] foo = [1.0, 2.0];
 is accepted, which is a bit strange (I think the compiler 
 should give at least a warning if too many elements are 
 reserved for an array).

I just read that as "the other are NaN/.init initialized", which 
seems reasonable. The dollar notation is better than the warning 
here, to say that the array initializer is the authoritative 
source of the array length.

"eles" <eles eles.com> writes:

On Friday, 26 April 2013 at 15:59:32 UTC, Luís Marques wrote:
 On Friday, 26 April 2013 at 15:45:27 UTC, eles wrote:
 which reminds me about the proposal to allow declaration of 
 static arrays with
 double[$] foo = [1.0, 2.0, void, 3.0, 3.5, void, void, void];

 Seems nice.

 double[4] foo = [1.0, 2.0];
 is accepted, which is a bit strange (I think the compiler 
 should give at least a warning if too many elements are 
 reserved for an array).

 I just read that as "the other are NaN/.init initialized", 
 which seems reasonable. The dollar notation is better than the 
 warning here, to say that the array initializer is the 
 authoritative source of the array length.

I thought about it. However, it is not very nice. What if 
somebody types 1024 instead of 024 for an array length? The error 
could pass through the compiler and crash an out of memory after 
years of use.

OTOH, I would like to be able to specify a partial initialization 
of the first elements of an array, then a default/imposed value 
for the remaining elements. So, what about:

double[4] foo = [1.0, 2.0 .. ]; //initializes last 3 elements to 
2.0

In this case, obviously, one cannot write

double[$] foo = [1.0, 2.0 .. ]; //the compiler cannot deduce 
length of static array

Speaking about the proposal of using "$" in declaring static 
arrays whose elements the compiler is able to count (just like in 
the double[$] foo = [1.0, 2.0];) I wonder sometimes why so much 
reluctance to implement those simple changes (and almost 
obvious), while other more dramatic changes are sometimes taken 
in a rush. Do not ask for examples, it is a feeling mainly 
derived from the discussions about those  property-ies. Speaking 
about, what decision was reached to get rid of the compiler 
-property flag which is a monster per se? (changes the way the 
language is defined).

"John Colvin" <john.loughran.colvin gmail.com> writes:

On Friday, 26 April 2013 at 14:58:35 UTC, Luís Marques wrote:
 Should this be supported?

     double[8] foo = [1.0, 2.0, void, 3.0, 3.5, void, void, 
 void];

 (it's not supported at the moment)

Why would you ever want this? I can't even think of a 
hypothetical use case.

=?UTF-8?B?Ikx1w61z?= Marques" <luismarques gmail.com> writes:

On Friday, 26 April 2013 at 17:58:04 UTC, John Colvin wrote:
 Why would you ever want this? I can't even think of a 
 hypothetical use case.

The questions started as academic, motivated by the apparent lack 
of orthogonality. As far as a practical scenario, right now this 
is the best I can come up with:

     // emulator, ROM and RAM accessible from the same bus (von 
Neumann)
     byte[1024] romAndRam = [0x42, 0x77, 0xAF, 0x44, void];

(this relies also on eles' suggestion, the void is assumed for 
the remaining elements -- the RAM part).

I'm not saying that this should be supported. I was asking if 
something like this should be :-)

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Fri, 26 Apr 2013 07:58:34 -0700, Lu=C3=ADs Marques <luismarques gmail=
.com>  =

wrote:

 Should this be supported?

      double[8] foo =3D [1.0, 2.0, void, 3.0, 3.5, void, void, void];

 (it's not supported at the moment)

Have you considered what this does?  Consider a standard [1.0, 2.0] call=
:

In essence, it pushes 1.0 and 2.0 onto the stack, then calls a function =
to  =

allocate the memory and use the given data.

What will end up happening is the data is copied from the stack to the  =

heap.  It's just in your case, the data copied is garbage.  I see little=
  =

point in supporting this.

-Steve

Timon Gehr <timon.gehr gmx.ch> writes:

On 04/27/2013 07:29 AM, Steven Schveighoffer wrote:
 On Fri, 26 Apr 2013 07:58:34 -0700, Luís Marques <luismarques gmail.com>
 wrote:

 Should this be supported?

      double[8] foo = [1.0, 2.0, void, 3.0, 3.5, void, void, void];

 (it's not supported at the moment)

 Have you considered what this does?  Consider a standard [1.0, 2.0] call:

 In essence, it pushes 1.0 and 2.0 onto the stack, then calls a function
 to allocate the memory and use the given data.

 What will end up happening is the data is copied from the stack to the
 heap.  It's just in your case, the data copied is garbage.  I see little
 point in supporting this.

 -Steve

(This is a DMD performance bug.)

"deadalnix" <deadalnix gmail.com> writes:

On Saturday, 27 April 2013 at 05:29:41 UTC, Steven Schveighoffer 
wrote:
 On Fri, 26 Apr 2013 07:58:34 -0700, Luís Marques 
 <luismarques gmail.com> wrote:

 Should this be supported?

     double[8] foo = [1.0, 2.0, void, 3.0, 3.5, void, void, 
 void];

 (it's not supported at the moment)

 Have you considered what this does?  Consider a standard [1.0, 
 2.0] call:

 In essence, it pushes 1.0 and 2.0 onto the stack, then calls a 
 function to allocate the memory and use the given data.

 What will end up happening is the data is copied from the stack 
 to the heap.  It's just in your case, the data copied is 
 garbage.  I see little point in supporting this.

 -Steve

That is an implementation detail.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Sat, 27 Apr 2013 06:43:58 -0700, deadalnix <deadalnix gmail.com> wrot=
e:

 On Saturday, 27 April 2013 at 05:29:41 UTC, Steven Schveighoffer wrote=

:
 On Fri, 26 Apr 2013 07:58:34 -0700, Lu=C3=ADs Marques  =


 <luismarques gmail.com> wrote:

 Should this be supported?

     double[8] foo =3D [1.0, 2.0, void, 3.0, 3.5, void, void, void];

 (it's not supported at the moment)

 Have you considered what this does?  Consider a standard [1.0, 2.0]  =


 call:

 In essence, it pushes 1.0 and 2.0 onto the stack, then calls a functi=


on  =

 to allocate the memory and use the given data.

 What will end up happening is the data is copied from the stack to th=


e  =

 heap.  It's just in your case, the data copied is garbage.  I see  =


 little point in supporting this.

 -Steve

 That is an implementation detail.

Oh, I didn't notice that foo was a fixed-sized array, I thought the focu=
s  =

was on the array literal.

It does make sense that this should be possible.

-Steve

Stewart Gordon <smjg_1998 yahoo.com> writes:

On 27/04/2013 06:29, Steven Schveighoffer wrote:
<snip>
 Have you considered what this does?  Consider a standard [1.0, 2.0] call:

 In essence, it pushes 1.0 and 2.0 onto the stack, then calls a function
 to allocate the memory and use the given data.

<snip>

Does it?  I would have thought it stores the numbers in the static data 
segment, and uses a block memory copy in order to use it to initialise a 
static array.

This would explain why initialising individual elements as void isn't 
supported.  The point of initialising as void is to eliminate the 
overhead of initialising when you're just going to populate the array 
programmatically anyway.  But with a block memory copy you can't skip 
over individual elements, so would have to initialise it bit by bit, 
which defeats the point since void is supposed to eliminate overhead, 
not create more.

Stewart.

-- 
My email address is valid but not my primary mailbox and not checked 
regularly.  Please keep replies on the 'group where everybody may benefit.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Fri, 17 May 2013 02:46:31 -0400, Stewart Gordon <smjg_1998 yahoo.com>  
wrote:

 On 27/04/2013 06:29, Steven Schveighoffer wrote:
 <snip>
 Have you considered what this does?  Consider a standard [1.0, 2.0]  
 call:

 In essence, it pushes 1.0 and 2.0 onto the stack, then calls a function
 to allocate the memory and use the given data.

 <snip>

 Does it?  I would have thought it stores the numbers in the static data  
 segment, and uses a block memory copy in order to use it to initialise a  
 static array.

Last time I checked, that's what it did.  But it may have changed.

As Timon and deadalnix say, it's a bug in implementation.  In any case, I  
was focusing only on the [] expression, not the fact that you are  
initializing a static array.  The static array initialization should  
change how the expression is handled.

-Steve