import std.stdio;
class A
{
int[] c = [3,3];
}
void main()
{
int[] a = [2,2];
int[] b = [2,2];
a[0] = 33;
assert(b[0] == 2); // success
A ca = new A;
A cb = new A;
ca.c[0] = 44;
assert(cb.c[0] == 3); // failure: value is 44
}
Comment #1 by gide — 2009-05-07T03:32:13Z
*** Bug 2948 has been marked as a duplicate of this bug. ***
Comment #2 by yebblies — 2012-02-01T19:29:15Z
*** Issue 4378 has been marked as a duplicate of this issue. ***
Comment #3 by nilsbossung — 2013-06-20T07:39:15Z
*** Issue 10423 has been marked as a duplicate of this issue. ***
Comment #4 by iteronvexor — 2013-06-21T08:58:32Z
How many years before this is fixed, god damn.
Comment #5 by yebblies — 2013-11-20T03:45:58Z
Similar thing for classes in issue 11107
Comment #6 by yebblies — 2013-11-21T07:53:57Z
*** Issue 10108 has been marked as a duplicate of this issue. ***
Comment #7 by jakobovrum — 2015-12-05T16:10:56Z
(In reply to Georg Wrede from comment #0)
> ...
Member field initializers are always evaluated at compile-time so this behaviour is not a bug. The bug is that the array elements are allocated in global memory instead of TLS. Only `immutable` and `shared` elements should be allocated in global memory. We can also do it for `const` elements as CTFE should always be pure enough to assume uniqueness.
Same issue as CT initializers of mutable class type, i.e.
void main()
{
static Object o = new Object; // stored in global memory; should be TLS
}
Comment #8 by yebblies — 2015-12-05T16:33:17Z
(In reply to Jakob Ovrum from comment #7)
> (In reply to Georg Wrede from comment #0)
> > ...
>
> Member field initializers are always evaluated at compile-time so this
> behaviour is not a bug. The bug is that the array elements are allocated in
> global memory instead of TLS. Only `immutable` and `shared` elements should
> be allocated in global memory. We can also do it for `const` elements as
> CTFE should always be pure enough to assume uniqueness.
>
> Same issue as CT initializers of mutable class type, i.e.
>
> void main()
> {
> static Object o = new Object; // stored in global memory; should be TLS
> }
How exactly would putting the array in TLS fix this bug?
Comment #9 by jakobovrum — 2015-12-05T16:37:00Z
(In reply to yebblies from comment #8)
> How exactly would putting the array in TLS fix this bug?
Sigh, like I said, the code in the bug report is *not* a bug.
I mention TLS because one of the "duplicates" correctly identify this as an issue.
Comment #10 by jakobovrum — 2015-12-05T17:13:17Z
(In reply to Jakob Ovrum from comment #9)
> (In reply to yebblies from comment #8)
> > How exactly would putting the array in TLS fix this bug?
>
> Sigh, like I said, the code in the bug report is *not* a bug.
That said, as has been suggested in the case of class types, it might be a sensible solution to disallow mutable types in these cases, in which case it's "accepts invalid".
Comment #11 by yebblies — 2016-03-19T14:50:47Z
(In reply to Jakob Ovrum from comment #9)
> (In reply to yebblies from comment #8)
> > How exactly would putting the array in TLS fix this bug?
>
> Sigh, like I said, the code in the bug report is *not* a bug.
>
Well, you're wrong. It should not be shared between class instances at all.
Comment #12 by jakobovrum — 2016-03-19T15:13:09Z
(In reply to yebblies from comment #11)
> Well, you're wrong. It should not be shared between class instances at all.
It would be consistent with every other static initializer in the language. If you're going to take a stand please provide some kind of rationale, otherwise surely the exercise is just meaningless noise.
Comment #13 by yebblies — 2016-03-19T15:45:15Z
(In reply to Jakob Ovrum from comment #12)
> (In reply to yebblies from comment #11)
> > Well, you're wrong. It should not be shared between class instances at all.
>
> It would be consistent with every other static initializer in the language.
> If you're going to take a stand please provide some kind of rationale,
> otherwise surely the exercise is just meaningless noise.
I have no idea why you think that two class instances automatically sharing mutable state is intentional. There's plenty of discussion in the duplicates of this bug.
Comment #14 by dfj1esp02 — 2017-08-22T13:40:48Z
*** Issue 13646 has been marked as a duplicate of this issue. ***
Comment #15 by dfj1esp02 — 2017-08-22T13:44:25Z
Applicable to static variables too. Probably breaks @safety.
Comment #16 by dfj1esp02 — 2017-08-22T13:59:27Z
Class initializer from issue 11107:
class A{}
struct S
{
auto a = new A;
}
Comment #17 by dfj1esp02 — 2017-08-22T14:05:10Z
*** Issue 17604 has been marked as a duplicate of this issue. ***
Comment #18 by robert.schadek — 2024-12-13T17:50:05Z