Thread overview
magically a static member on init?
Nov 14, 2020
Martin
Nov 14, 2020
Adam D. Ruppe
Nov 14, 2020
Martin
Nov 17, 2020
Kagamin
Nov 15, 2020
H. S. Teoh
Nov 15, 2020
Martin
Nov 16, 2020
H. S. Teoh
November 14, 2020
Hi, i do no know if this is intended - but imo this is weird:
https://run.dlang.io/is/eBje3A

I expected that `c.a.str == ""` (just like `c.str` is). But instead `c.a.str` keeps the value of `b.a.str`.

Is this intentional? IMO this feels not consistent and its weird when a reference leaks into another instance without having declared it static member.

Greetigs
November 14, 2020
On Saturday, 14 November 2020 at 23:20:55 UTC, Martin wrote:
> Is this intentional?

In the current language design, yes. For the many users who ask this, no.

All static initializers are run at compile time and refer to the static data segment - this is consistent across the language.

static x = y; // y is run at compile time

struct A {
    int[] a = [1,2,3]; // array built t compile time
}

so.....

void main() {
   A a;
   a.a[0] = 5;
   A b;
   b.a[0] == 5; // true!!!
}


Because both actually share the same initial array reference.


And with classes again, same deal. *Constructors* are run for each instance. But the rest of it is part of the static initializer that is shared....

> IMO this feels not consistent and its weird when a reference leaks into another instance without having declared it static member.


Yeah, it is weird and a frequent mistake people make, I almost wish it had to be more explicit (I'd be sad if it was removed though, I actually use this in places!).

But once you understand it it kinda makes sense.

Note btw that the reference itself is NOT static... just the object it refers to. So if you do

obj.a  = new Thing

then it doesn't affect other objects, just this one. But they all start off pointing to the same thing.
November 14, 2020
On Saturday, 14 November 2020 at 23:30:58 UTC, Adam D. Ruppe wrote:
> On Saturday, 14 November 2020 at 23:20:55 UTC, Martin wrote:
>> Is this intentional?
> [...]

alright, thank you! :)
November 14, 2020
On Sat, Nov 14, 2020 at 11:20:55PM +0000, Martin via Digitalmars-d-learn wrote:
> Hi, i do no know if this is intended - but imo this is weird: https://run.dlang.io/is/eBje3A
> 
> I expected that `c.a.str == ""` (just like `c.str` is). But instead `c.a.str` keeps the value of `b.a.str`.
> 
> Is this intentional? IMO this feels not consistent and its weird when a reference leaks into another instance without having declared it static member.
[...]

This is a known "feature".  Using a `new` expression as a field initializer will initialize it once at program startup, and the reference is copied thereafter into all instances of the class.

If you want separate instances per class instantiation, move the `new` into the constructor instead.

Yes, it does feel weird, and IMNSHO it's a misfeature. But it is what it is; if you don't like the semantics, don't use it; always allocate the field in the class ctor instead.


T

-- 
The fact that anyone still uses AOL shows that even the presence of options doesn't stop some people from picking the pessimal one. - Mike Ellis
November 15, 2020
On Sunday, 15 November 2020 at 00:29:41 UTC, H. S. Teoh wrote:
> if you don't like the semantics, don't use it; always allocate the field in the class ctor instead.

Hi, i neither like it nor dislike it - it just caught me by surprise because i was under the impression that if i create a new instance then all members get initialized according to the declared optional default value.

I can see how this is a feature - but it is also of kind "expert knowledge" and i would argue that "expert knowladge" is a designs arch enemy.
November 16, 2020
On Sun, Nov 15, 2020 at 10:06:55AM +0000, Martin via Digitalmars-d-learn wrote:
> On Sunday, 15 November 2020 at 00:29:41 UTC, H. S. Teoh wrote:
> > if you don't like the semantics, don't use it; always allocate the field in the class ctor instead.
> 
> Hi, i neither like it nor dislike it - it just caught me by surprise because i was under the impression that if i create a new instance then all members get initialized according to the declared optional default value.
> 
> I can see how this is a feature - but it is also of kind "expert knowledge" and i would argue that "expert knowladge" is a designs arch enemy.

Oh, I don't disagree; I think it's a bad design choice, and I don't think I'd ever use this construct personally.  But it's there, and if you use it, then you just have to be aware of the gotchas. :-)


T

-- 
Insanity is doing the same thing over and over again and expecting different results.
November 17, 2020
On Saturday, 14 November 2020 at 23:30:58 UTC, Adam D. Ruppe wrote:
> On Saturday, 14 November 2020 at 23:20:55 UTC, Martin wrote:
>> Is this intentional?
>
> In the current language design, yes.

It's a bug, it breaks data sharing guarantees.
November 17, 2020
On Tuesday, 17 November 2020 at 13:24:03 UTC, Kagamin wrote:
> On Saturday, 14 November 2020 at 23:30:58 UTC, Adam D. Ruppe wrote:
>> On Saturday, 14 November 2020 at 23:20:55 UTC, Martin wrote:
>>> Is this intentional?
>>
>> In the current language design, yes.
>
> It's a bug, it breaks data sharing guarantees.

Hah, yes. Init actually should be thread local for this to work out...
Ref shared semantics...