digitalmars.D.learn - Qualified destructors / immutable objects
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (18/18) Jun 12 2015 struct S {
- anonymous (37/40) Jun 12 2015 a.d:
- anonymous (24/24) Jun 12 2015 no need for ~this() to modify immutable data:
-
"Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>
(3/4)
Jun 12 2015
- Daniel Kozak (3/27) Jun 13 2015 Is there an existing issue on issue.dlang.org? If not can you
- anonymous (1/3) Jun 13 2015 https://issues.dlang.org/show_bug.cgi?id=10376
- anonymous (25/25) Jun 14 2015 To come back to destructors and immutable objects:
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (5/30) Jun 14 2015 Found this bug report [1], in which Andrei says: "Mutable
struct S { int x; ~this() { import std.stdio; writeln("mutable ~this()"); x = 1; } } void main() { const(S) s1; immutable(S) s2; } Prints: mutable ~this() mutable ~this() This looks very wrong, although I cannot find a way to actually modify immutable memory with it... Is it a bug?
Jun 12 2015
I cannot find a way to actually modify immutable memory with it...a.d: class C { int a; this(int a) { this.a = a; } } struct S { int x; C elem = new C(42); ~this() { import std.stdio; writeln("mutable ~this()"); x = 1; elem.a = 123; } } void foo() { S s2; } void main() { import std.stdio; immutable(S) s1; // Error: cannot modify immutable expression s1.elem.a // s1.elem.a = 43; writeln(s1.elem.a); foo(); writeln(s1.elem.a); } dmd a.d ./a prints: 42 mutable ~this() 123 mutable ~this()Is it a bug?I'll wait with a bug report, but I think this should be forbidden.
Jun 12 2015
no need for ~this() to modify immutable data: class C { int a; this(int a) { this.a = a; } } struct S { C elem = new C(42); } void main() { import std.stdio; immutable(S) s1; // Error: cannot modify immutable expression s1.elem.a // s1.elem.a = 43; writeln(s1.elem.a); S s2; s2.elem.a = 123; writeln(s1.elem.a); } Prints: 42 123
Jun 12 2015
On Friday, 12 June 2015 at 15:36:22 UTC, anonymous wrote:no need for ~this() to modify immutable data:<snip> I think that's a another bug related to init values.
Jun 12 2015
On Friday, 12 June 2015 at 15:36:22 UTC, anonymous wrote:no need for ~this() to modify immutable data: class C { int a; this(int a) { this.a = a; } } struct S { C elem = new C(42); } void main() { import std.stdio; immutable(S) s1; // Error: cannot modify immutable expression s1.elem.a // s1.elem.a = 43; writeln(s1.elem.a); S s2; s2.elem.a = 123; writeln(s1.elem.a); } Prints: 42 123Is there an existing issue on issue.dlang.org? If not can you report it
Jun 13 2015
Is there an existing issue on issue.dlang.org? If not can you report ithttps://issues.dlang.org/show_bug.cgi?id=10376
Jun 13 2015
To come back to destructors and immutable objects: Even without the default initialized variables issue it is possible to modify immutable data: struct S { int[] bar; ~this() { bar[0] = 123; } } void foo(immutable(int[]) i) { immutable(S) s = immutable S(i); } void main() { immutable array = [42, 42]; foo(array); // fails assert(array == [42, 42]); } I'm not sure whether ~this() should be forbidden to modify immutable data. Consider e.g. some fields need to be free'd. If someone else is using references to such a field after ~this() -> segfault, but it could be seen as analogon to the list of undefined operations on pointer to GC memory. Additionally the same happens already for stack allocated fields like int[4] inside a (mutable/const/immutable) struct.
Jun 14 2015
On Sunday, 14 June 2015 at 07:28:39 UTC, anonymous wrote:To come back to destructors and immutable objects: Even without the default initialized variables issue it is possible to modify immutable data: struct S { int[] bar; ~this() { bar[0] = 123; } } void foo(immutable(int[]) i) { immutable(S) s = immutable S(i); } void main() { immutable array = [42, 42]; foo(array); // fails assert(array == [42, 42]); } I'm not sure whether ~this() should be forbidden to modify immutable data. Consider e.g. some fields need to be free'd. If someone else is using references to such a field after ~this() -> segfault, but it could be seen as analogon to the list of undefined operations on pointer to GC memory. Additionally the same happens already for stack allocated fields like int[4] inside a (mutable/const/immutable) struct.Found this bug report [1], in which Andrei says: "Mutable destructors shouldn't apply to objects that were immutable, otherwise they can mutate immutable objects." [1] https://issues.dlang.org/show_bug.cgi?id=4338#c6
Jun 14 2015