On Friday, 10 June 2022 at 07:49:43 UTC, Mike Parker wrote:
> ...
> And it *is* documented:
>
>> Struct fields are by default initialized to whatever the Initializer for the field is, and if none is supplied, to the default initializer for the field's type.
>> The default initializers are evaluated at compile time.
>
> https://dlang.org/spec/struct.html#default_struct_init

Hmm I understand the text but for this intializers I was expecting new address with length 5, for example:

import std.stdio;

struct S{
    int[] arr = new int[](5);
    int[2] arr2;
}

void main(){
    S s1, s2;

    s2.arr[0] = 42;
    writeln(s1.arr[0], " address: ", &s1.arr[0]);
    writeln(s2.arr[0], " address: ", &s2.arr[0]);

    s2.arr2[0] = 10;
    writeln(s1.arr2[0], " address: ", &s1.arr2[0]);
    writeln(s2.arr2[0], " address: ", &s2.arr2[0]);
}

Prints:

42 address: 5586F5BD9CC0
42 address: 5586F5BD9CC0
 0 address: 7FFFC65C7A20
10 address: 7FFFC65C7A40


And as it can be seen: s1.arr and s2.arr shares the same address.

So, in the case of "int[] arr = new int[](5)", an array of length 5 of type int will be instantiated and its address will be shared among whoever instantiates "S" and be pointed and accessed through arr.

In the second case, "int[2] arr2", 2 consecutive integer spaces in memory will be allocate independently for each "instantiation" of "S", so different address.

I never saw this before (I mean I never wrote the first case), I'm used to the "int[2] arr2;" way of declaring it, but if I had looked this code without knowing this, I'd be certain that s1.arr and s2.arr would have different addresses.

This is a bit weird (At least for a newbie like me), I really think the compiler should emit an warning about this.

Matheus.

On Saturday, 11 June 2022 at 01:52:58 UTC, Mike Parker wrote:
> ...
> That's because static arrays are allocated as part of the instance:
> ...

Yes I understood the problem, but the naive me was thinking that in this example:

struct S{
    int[] arr = new int[](5);
}

For some reason this would be transformed as a statically "int[5] arr" in the case of structs.

But now I see that's not the case and "arr" points to whatever was allocated by "new", and will share across the instances of S (Since it's the same address).

> ... So would you then really want a warning every time you initialize a static array field?

Well would this be annoying? Yes, mainly if I already know this, but if not, then it would be like a nice to know warning for newbies like myself. By the way this would be only in the cases that a static array field being initialized with dynamic allocation like in the case of struct declaration, not on every place.

> ...
> So the question in each case would be, where's the line between helpful and annoying?

Well I like to think about this like the "-Wall" flag in C compilers, you need to go for it, and you just dismiss the warning in such case if you don't agree or know what you're doing.

> ...
> The compiler should be as helpful as it can, but it has to be helpful without getting in the way. There's a significant amount of learning by trial and error in any programming language. So I think there has to be a distinction between things like "easy to do by accident even when you know the deal"  and "once you learn it, you're unlikely to do it again".

Yes no doubt about it, by the way like I said, I never used this form to initialize fields in structs, I always used the "T[n] member", but in this particular case the result would have been very different from what I expected.

Anyway I'm always lurking around this Forum and learning new things.

Thanks,

Matheus.

PS: I'm ESL so sorry for my English mistakes.