Jump to page: 1 2
Thread overview
[Issue 2947] Array literal changeable if part of class.
Dec 05, 2015
Jakob Ovrum
Dec 05, 2015
yebblies
Dec 05, 2015
Jakob Ovrum
Dec 05, 2015
Jakob Ovrum
Mar 19, 2016
yebblies
Mar 19, 2016
Jakob Ovrum
Mar 19, 2016
yebblies
Aug 22, 2017
anonymous4
Aug 22, 2017
anonymous4
Aug 22, 2017
anonymous4
[Issue 2947] Static initializer stored in mutable non-TLS global
Aug 22, 2017
anonymous4
Aug 22, 2017
anonymous4
December 05, 2015
https://issues.dlang.org/show_bug.cgi?id=2947

Jakob Ovrum <jakobovrum@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakobovrum@gmail.com

--- Comment #7 from Jakob Ovrum <jakobovrum@gmail.com> ---
(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
}

--
December 05, 2015
https://issues.dlang.org/show_bug.cgi?id=2947

--- Comment #8 from yebblies <yebblies@gmail.com> ---
(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?

--
December 05, 2015
https://issues.dlang.org/show_bug.cgi?id=2947

--- Comment #9 from Jakob Ovrum <jakobovrum@gmail.com> ---
(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.

--
December 05, 2015
https://issues.dlang.org/show_bug.cgi?id=2947

--- Comment #10 from Jakob Ovrum <jakobovrum@gmail.com> ---
(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".

--
March 19, 2016
https://issues.dlang.org/show_bug.cgi?id=2947

--- Comment #11 from yebblies <yebblies@gmail.com> ---
(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.

--
March 19, 2016
https://issues.dlang.org/show_bug.cgi?id=2947

--- Comment #12 from Jakob Ovrum <jakobovrum@gmail.com> ---
(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.

--
March 19, 2016
https://issues.dlang.org/show_bug.cgi?id=2947

--- Comment #13 from yebblies <yebblies@gmail.com> ---
(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.

--
August 22, 2017
https://issues.dlang.org/show_bug.cgi?id=2947

anonymous4 <dfj1esp02@sneakemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |floating.point@rambler.ru

--- Comment #14 from anonymous4 <dfj1esp02@sneakemail.com> ---
*** Issue 13646 has been marked as a duplicate of this issue. ***

--
August 22, 2017
https://issues.dlang.org/show_bug.cgi?id=2947

anonymous4 <dfj1esp02@sneakemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid, spec
                URL|                            |https://dlang.org/spec/clas
                   |                            |s.html#constructors
           Hardware|x86                         |All
                 OS|Linux                       |All

--- Comment #15 from anonymous4 <dfj1esp02@sneakemail.com> ---
Applicable to static variables too. Probably breaks @safety.

--
August 22, 2017
https://issues.dlang.org/show_bug.cgi?id=2947

anonymous4 <dfj1esp02@sneakemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://issues.dlang.org/sh
                   |                            |ow_bug.cgi?id=11107

--
« First   ‹ Prev
1 2