Bug 780 – (D1 only) The assignment of 'this' is allowed

The compiler allows assignment of the 'this' special reference. Instead 'this' should be final (i.e., non assignable). In some cases, like in a class constructor, 'this' is treated as if an inout reference, changing a variable in another scope: -------- -------- import std.stdio; class Foo { static bool first = true; this() { if(first){ first = false; this = new Foo(); writefln("this= ", cast(void *)this); } } } void main(char[][] args) { Foo foo = new Foo(); writefln("foo= ", cast(void *)foo); } -------- outputs: -------- this before= 8B0FE0 this after= 8B0FD0 foo= 8B0FD0

http://www.digitalmars.com/d/class.html#constructors # Constructors are defined with a function name of this and having no return value However the compiler implements class constructors as returning the this pointer # # module wood; # class Tree{ # this(){ # } # } # dmd -c wood.d && nm wood.o | grep _ctor | sed "s:.* ::" _D4wood4Tree5_ctorMFZC4wood4Tree demangled: wood.Tree wood.Tree.this(this)

Before and after return the same thing in 2.051. Nevertheless, assigning to this should be syntactically disallowed.

The spec now disallows assignment to this and super, but the compiler still allows it. Since code like gtkd relies on allowing it, the progression should be: 1. spec change 2. make it a warning 3. deprecate it 4. remove from compiler This will take time. We're at (1). So the bug stays open for now.

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

After fixing bug 4596, this will be an issue for only D1.

(In reply to comment #5) > After fixing bug 4596, this will be an issue for only D1. Bug 4596 is fixed.

Running the original example on git HEAD on an Ubuntu 16.04 machine results in compilation failure with the message "This is not an lvalue". Closing as fixed.

Reopening, this is a D1 only bug. I'm not in a position to test, but I can't tell if you mean that you tested on the HEAD for D1 or not. I can't imagine this got fixed by accident in D1.

(In reply to Steven Schveighoffer from comment #8) > Reopening, this is a D1 only bug. I'm not in a position to test, but I can't > tell if you mean that you tested on the HEAD for D1 or not. I can't imagine > this got fixed by accident in D1. Sorry for my lack of rigorousness. I tested on D2. My understanding is that D1 is not maintained anymore so I don't see the point in keeping bugs for D1 in bugzilla.

Companies such as Sociomantic still uses D1 for now, and have certainly been able to get D1 fixes through when they need it. So D1 isn't quite "dead" yet. In this particular case, I tend to agree that it's likely not going to be addressed as it doesn't really affect any "good" code. But until Walter says "no more D1 fixes period", we should at least leave the bug reports for D1 open. I'd also suggest that at some point, if D1 is truly dead, we don't "close" all these issues, because anyone who may still use D1 may want to know what issues haven't been fixed (and won't be). Perhaps a new status type can be added, not sure how customizable bugzilla is in this regard. Alternatively, we can fork bugzilla into another location where D1 bugs don't interfere with D2 reports.

At this years Dconf it was decided that we can close issues that regarding D1 that are fixed in D2.