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)

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;

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

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.

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).

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.

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).

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.

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 :-)

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