FeepingCreature 
Posted in reply to Jonathan M Davis
| On Monday, 8 January 2024 at 05:22:20 UTC, Jonathan M Davis wrote:
> On Sunday, January 7, 2024 9:14:48 PM MST matheus via Digitalmars-d wrote:
>> On Sunday, 7 January 2024 at 23:12:30 UTC, Hipreme wrote:
>> > ...
>>
>> For what it seems this happens only with arrays?
>>
>> This happened with for example int[] a; but when I tried with
>> other types (Non-arrays) like (string, int) this problem didn't
>> occur.
>>
>> Since like in this example string arrays are pointers, I think something was messed-up with the address.
>>
>> Matheus.
>
> Well, to an extent, the problem here is simply that the member variable is a type with mutable indirections. The dynamic array itself is just a pointer and a length, and mutating what it points to like the OP's example doesn't actually mutate the init value. In order to avoid that sort of mutation, initializing the struct would need to give you a deep copy rather than a shallow copy. Other member variables with mutable indirections would have similar problems. For instance, all of the assertions in this code pass:
>
> class C
> {
> string foo = "foo";
> }
>
> struct S
> {
> C c = new C;
> }
>
> void main()
> {
> S s1;
> assert(s1.c.foo == "foo");
> assert(s1.c.foo == S.init.c.foo);
>
> S s2;
> s2.c.foo = "bar";
> assert(s2.c.foo == "bar");
>
> assert(s1.c.foo == "bar");
> assert(S.init.c.foo == "bar");
>
> assert((cast(void*)s1.c) is cast(void*)s2.c);
> assert((cast(void*)s1.c) is cast(void*)S.init.c);
>
> S s3;
> s3.c = new C;
> assert(s3.c.foo == "foo");
>
> assert(s1.c.foo == "bar");
> assert(s2.c.foo == "bar");
> assert(S.init.c.foo == "bar");
>
> assert((cast(void*)s1.c) is cast(void*)s2.c);
> assert((cast(void*)s1.c) is cast(void*)S.init.c);
>
> assert((cast(void*)s3.c) !is cast(void*)S.init.c);
> }
>
> The init value itself is never mutated, but what it points to is. Someone could interpret it like the init value had mutated, because what it's pointed to changed, and therefore, accessing the values via init then results in different values that were there at the start of the program, but technically, init itself never changed.
>
> As such, the OP should expect that mutating values in the array would affect any other variable when it's default-initialized, and I don't think that it's realistic for it to work any other way, because that requires making a deep copy of the init value rather than a shallow copy, and that's not something that can be done in the general case, because D doesn't have a mechanism for that.
>
> However, in spite of all of that, something weird is going on with the OP's example, because while variables that are created after the element of the array has been mutated see that mutation, the init value itself does not. So, it would appear that the array in the init value itself somehow ends up pointing to a different block of memory than the array does when the struct is default initilaized. This example shows the same problem
>
> struct S
> {
> int[] arr = [1, 2, 3];
> }
>
> void main()
> {
> S s1;
> assert(s1.arr == [1, 2, 3]);
> assert(s1.arr == S.init.arr);
>
> S s2;
> s2.arr[0] = 42;
> assert(s2.arr == [42, 2, 3]);
>
> assert(s1.arr == [42, 2, 3]);
> assert(S.init.arr == [1, 2, 3]);
> }
>
> and if I were to change main to
>
> void main()
> {
> import std.stdio;
> writeln(S.init.arr.ptr);
>
> S s1;
> writeln(s1.arr.ptr);
>
> S s2;
> writeln(s2.arr.ptr);
>
> writeln(S.init.arr.ptr);
> }
>
> running it on my computer results in
>
> C378D421000
> 2C3F08
> 2C3F08
> C378D421010
>
> So, for some reason, the ptr of the array in the init value has a different address from the one in the struct's after they've been default-initialized, but the struct's get the same pointer value.
>
> This is in stark contrast to my previous example where the member variable that was a class reference ended up with the address being the same for both the init value and the default-initialized structs. So, it would appear that the compiler or runtime is doing something different with dynamic arrays than it is with classes, and the behavior definitely seems wrong, because it means that a default-initialized struct does not match its init value - and this without worrying about mutating anything. e.g. this assertion fails when it should never fail
>
> struct S
> {
> int[] arr = [1, 2, 3];
> }
>
> void main()
> {
> S s;
> assert(s is S.init);
> }
>
> So, I would say that there is definitely a bug here with regards to init values when a struct has a member variable which is a dynamic array.
>
> However, ultimately, that's not really what the OP seems to be complaining about. Rather, he seems to be complaining about the fact that if you mutate a member variable with mutable indirections which were not null in the init value, then the changes to those mutable indirections are visible via the init value, and I don't think that that's something that's ever going to change, because it would require that default initialization do a deep copy rather than a shallow copy. Obviously, it can be surprising if it's not something that you've run into or thought through before, but D doesn't have a generic way to do deep copies, and you wouldn't necessarily want a deep copy in all cases anyway, so even if we could make it do a deep copy, that wouldn't necessarily be a good change for the language as a whole, though it would certainly fix the issue that the OP ran into.
>
> Arguably, what the OP needs is a default constructor rather than an init value, but that's not the way that D is designed, and it would be problematic with some of its features to use default construction instead (though this is far from the only case where not having default construction for structs can be annoying).
>
> - Jonathan M Davis
Force default values to be typed immutable?
|
Permalink
Reply
