Bug 10376 – Mutable field initializer reference is accessible through immutable aggregate

DMD 2.063: class C{ int[] x=[1,2,3]; } void main(){ auto c = new immutable(C)(); auto d = new C(); static assert(is(typeof(c.x[0])==immutable)); assert(c.x[0]==1); d.x[0]=2; assert(c.x[0]==2); }

This could be fixed by having two versions of C.x, one in the writable and one in the non-writable data segment.

Surely the bigger bug here is that they share the same array, regardless of mutability? I would expect each instance of C to default with a new array.

(In reply to comment #2) > Surely the bigger bug here is that they share the same array, regardless of > mutability? There is in fact an issue related to this: http://d.puremagic.com/issues/show_bug.cgi?id=2947 If it is valid, then this can be treated as a duplicate, but the spec is silent about it. OTOH, the spec states that immutable memory does not change during its lifetime, legitimizing this report. > I would expect each instance of C to default with a new array. Currently, there is one static init block that is blitted over the class memory before the constructor is called. What you suggest would IMO be another valid way to resolve this issue.

This seems to be a general problem with default initialised variables, not only arrays declared classes: http://forum.dlang.org/thread/[email protected]#post-klfhepckofdbsakmjafq:40forum.dlang.org still valid issue with 2.067.

The quickest way to stop the bleeding is to disallow the code. It's incorrect for immutable data and misleading for mutable data. (What an user might expect is that each data comes with a distinct array.)

This should be legal if the member variable is initialized with an immutable value, since that doesn't create any holes in the type system. In fact, if it weren't for issue# 12624, SysTime would have a default value for its timezone which was immutable (with timezone being Rebindable!(immutable TimeZone) ). But of course that requires that the member variable either be immutable or something like Rebindable, immutable(T)*, or immutable(T)[] which can point/refer to an immutable value but is not itself immutable. However, it's definitely the case that this should be disallowed when the initializer is mutable, and while it _could_ work with a const initializer under some set of circumstances, it's way simpler to just disallow it.

@ntrel updated dlang/dmd pull request #16347 "Require @system for field initializers with mutable reference types" fixing this issue: - Require @system for field initializers with mutable reference types Enabled with -preview=unsafeFieldInit. Fixes Bugzilla 10376 - Mutable field initializer reference is accessible through immutable aggregate https://github.com/dlang/dmd/pull/16347

*** Issue 15612 has been marked as a duplicate of this issue. ***

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18611 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB