www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - this as lvalue?

reply JMRyan <nospam nospam.com> writes:
I wouldn't have thought of "this" representing an lvalue.  However, the
following absurdity compiles and executes flawlessly.  Just don't
uncomment the assignment to y.i! 

class Yikes
{
    int i;
    this() { this = null; }
}


void main()
{
    auto y = new Yikes();
    // y.i = 0;
}

Is this a bug in the compiler (v.2.047)?  Am I missing something in 
thinking it shouldn't be?
Sep 03 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
JMRyan:
 Is this a bug in the compiler (v.2.047)?  Am I missing something in 
 thinking it shouldn't be?

I think it's not a bug. It's not a common need, but a method may way want to swap this with another. In Phobos this is done on a struct, see: http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/stdio.d#L324 Bye, bearophile
Sep 03 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/3/10 16:03 CDT, bearophile wrote:
 JMRyan:
 Is this a bug in the compiler (v.2.047)?  Am I missing something in
 thinking it shouldn't be?

I think it's not a bug. It's not a common need, but a method may way want to swap this with another. In Phobos this is done on a struct, see: http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/stdio.d#L324 Bye, bearophile

For classes this must be an rvalue. Andrei
Sep 03 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/3/10 16:33 CDT, Jonathan M Davis wrote:
 Still, I don't know how you could make it a true rvalue.

It's very simple - make "this" the result of a hypothetical function call. Andrei
Sep 03 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 For classes this must be an rvalue.

OK. Why? Bye, bearophile
Sep 03 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/3/10 17:16 CDT, bearophile wrote:
 Andrei Alexandrescu:
 For classes this must be an rvalue.

OK. Why?

If you could change this from within a method you'd pretty much ruin everything about object orientation. Andrei
Sep 03 2010
prev sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Friday 03 September 2010 15:18:25 Andrei Alexandrescu wrote:
 On 9/3/10 17:16 CDT, bearophile wrote:
 Andrei Alexandrescu:
 For classes this must be an rvalue.

OK. Why?

If you could change this from within a method you'd pretty much ruin everything about object orientation. Andrei

On the bright side, except for the constructor, it should only change what happens in that one member function and anything member functions that are called from it (or called from something that's called from it), so it's not like it's going to break everything. But really, it shouldn't work. There's no value to it. It just allows for bugs, even if you have to work at it to get them. I'm 99% certain that you can't reassign this in C++, C#, or Java, and I'd sooner expect someone to be surprised that it's possible that actually want to be able to. It's useful for structs, but for classes, it has no value. And as you say, it effectively breaks object orientation. - Jonathan M Davis
Sep 03 2010
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Sep 4, 10 05:22, Andrei Alexandrescu wrote:
 On 9/3/10 16:03 CDT, bearophile wrote:
 JMRyan:
 Is this a bug in the compiler (v.2.047)? Am I missing something in
 thinking it shouldn't be?

I think it's not a bug. It's not a common need, but a method may way want to swap this with another. In Phobos this is done on a struct, see: http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/stdio.d#L324 Bye, bearophile

For classes this must be an rvalue. Andrei

If 'this' is an rvalue then it is not possible to take the address ('&this').
Sep 04 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/4/10 3:32 CDT, KennyTM~ wrote:
 On Sep 4, 10 05:22, Andrei Alexandrescu wrote:
 On 9/3/10 16:03 CDT, bearophile wrote:
 JMRyan:
 Is this a bug in the compiler (v.2.047)? Am I missing something in
 thinking it shouldn't be?

I think it's not a bug. It's not a common need, but a method may way want to swap this with another. In Phobos this is done on a struct, see: http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/stdio.d#L324 Bye, bearophile

For classes this must be an rvalue. Andrei

If 'this' is an rvalue then it is not possible to take the address ('&this').

And I think you shouldn't do that either! Andrei
Sep 04 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Saturday 04 September 2010 01:32:03 KennyTM~ wrote:
 On Sep 4, 10 05:22, Andrei Alexandrescu wrote:
 On 9/3/10 16:03 CDT, bearophile wrote:
 JMRyan:
 Is this a bug in the compiler (v.2.047)? Am I missing something in
 thinking it shouldn't be?

I think it's not a bug. It's not a common need, but a method may way want to swap this with another. In Phobos this is done on a struct, see: http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/stdio.d# L324 Bye, bearophile

For classes this must be an rvalue. Andrei

If 'this' is an rvalue then it is not possible to take the address ('&this').

And of what possible use would taking the address of an object reference be? - Jonathan M Davis
Sep 04 2010
prev sibling parent reply JMRyan <nospam nospam.com> writes:
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote in
news:i5rovm$1q4b$1 digitalmars.com: 
 
 For classes this must be an rvalue.
 
 Andrei

I reported this as issue 4819.
Sep 05 2010
next sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Sunday 05 September 2010 15:02:10 Andrej Mitrovic wrote:
 Does this mean assigning to fields won't be an option anymore when using
 this?
 
 E.g.:
 
 class Foo
 {
     int x;
     int y;
 
     void changeXY(int x, int y)
     {
         this.x = x;
         this.y = y;
     }
 }

No, it simply means that you won't be able to do this in a class: this = new MyObj(); In C++, this is a const pointer to non-const data in non-const functions and a const pointer to const data in const functions. The problem is that due to how D deals with const and references, you can't have this be a const reference to non-const data. And with the current implementation, that means that you can reassign this. Now, that's setting a local variable, so it only affects that function and any other member functions that it calls, but it's still not a good thing. If this in classes becomes an rvalue semantically-speaking (regardless of how its done under the hood), then you won't be able to assign to it anymore. But you should still be able to assign to anything that you get from it. Remember that this.x is dereferencing the this reference to get at the memory where x is. Whether you can assign to this is irrelevant for that. It's not trying to do anything to this itself, just what it refers to. - Jonathan M Davis
Sep 05 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Ok, thanks. I never liked the "lvalue rvalue" names.. For example
http://en.wikipedia.org/wiki/Value_%28computer_science%29

l-value, non-lvalue, rvalue, nonlvalue.. bleh. It's the same thing as
when I see "mutable, non-immutable, non-mutable, immutable" sprinkled
with a few tripple negatives all around in a piece of text.
/non-non-rant

On Mon, Sep 6, 2010 at 12:46 AM, Jonathan M Davis <jmdavisprog gmail.com> w=
rote:
 On Sunday 05 September 2010 15:02:10 Andrej Mitrovic wrote:
 Does this mean assigning to fields won't be an option anymore when using
 this?

 E.g.:

 class Foo
 {
 =A0 =A0 int x;
 =A0 =A0 int y;

 =A0 =A0 void changeXY(int x, int y)
 =A0 =A0 {
 =A0 =A0 =A0 =A0 this.x =3D x;
 =A0 =A0 =A0 =A0 this.y =3D y;
 =A0 =A0 }
 }

No, it simply means that you won't be able to do this in a class: this =3D new MyObj(); In C++, this is a const pointer to non-const data in non-const functions =

 const pointer to const data in const functions. The problem is that due t=

 deals with const and references, you can't have this be a const reference=

 non-const data. And with the current implementation, that means that you =

 reassign this. Now, that's setting a local variable, so it only affects t=

 function and any other member functions that it calls, but it's still not=

 thing. If this in classes becomes an rvalue semantically-speaking (regard=

 how its done under the hood), then you won't be able to assign to it anym=

 But you should still be able to assign to anything that you get from it.
 Remember that this.x is dereferencing the this reference to get at the me=

 where x is. Whether you can assign to this is irrelevant for that. It's n=

 trying to do anything to this itself, just what it refers to.

 - Jonathan M Davis

Sep 05 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/05/2010 05:02 PM, Andrej Mitrovic wrote:
 Does this mean assigning to fields won't be an option anymore when using this?

 E.g.:

 class Foo
 {
      int x;
      int y;

      void changeXY(int x, int y)
      {
          this.x = x;
          this.y = y;
      }
 }

No, guys, most everything will be the same. If you can write (new Foo).x = x, then you can also write this.x = x. Try it now! Andrei
Sep 05 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei:
 If you can write (new Foo).x = x, then you can also write this.x = x. Try it
now!

See my bug reports/enhancement requests (about three days ago in a program of mine I have added a bug that enhancement 4407 is able to avoid): Arguments and attributes with the same name http://d.puremagic.com/issues/show_bug.cgi?id=3878 Catch wrong argument<->attribute assignments in methods http://d.puremagic.com/issues/show_bug.cgi?id=4407 Bye, bearophile
Sep 05 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Andrej Mitrovic:
 ++ on that bug report.

Then vote for it :-) Bye, bearophile
Sep 06 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Friday 03 September 2010 14:22:46 Andrei Alexandrescu wrote:
 On 9/3/10 16:03 CDT, bearophile wrote:
 JMRyan:
 Is this a bug in the compiler (v.2.047)?  Am I missing something in
 thinking it shouldn't be?

I think it's not a bug. It's not a common need, but a method may way want to swap this with another. In Phobos this is done on a struct, see: http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/stdio.d# L324 Bye, bearophile

For classes this must be an rvalue. Andrei

There is no value in this being assignable in a class, but at the lower level of how the functions are actually declared underneath (with them taking this as an argument), it makes perfect sense that it would work. It certainly wouldn't be bad to disallow it though, since it's pointless and is just going to cause bugs, though generally not as bad as the ones in the OP's example (since he assigned to this in the constructor). Still, I don't know how you could make it a true rvalue. You'd need the ability to pass a const reference to non-const data to do that, and D doesn't allow for that. The invisible this parameter, being a reference, is going to suffer from all of the issues with const that have been oft-discussed (though, generally what people want is a non-const reference to const data rather than a const reference to non-const data like you would need for this). - Jonathan M Davis
Sep 03 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Does this mean assigning to fields won't be an option anymore when using this?

E.g.:

class Foo
{
    int x;
    int y;

    void changeXY(int x, int y)
    {
        this.x = x;
        this.y = y;
    }
}

On Sun, Sep 5, 2010 at 6:09 PM, JMRyan <nospam nospam.com> wrote:
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote in
 news:i5rovm$1q4b$1 digitalmars.com:
 For classes this must be an rvalue.

 Andrei

I reported this as issue 4819.

Sep 05 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Gmail likes to eat my code for some reason, it just ate two closing
parantheses.. lol.

On Mon, Sep 6, 2010 at 12:02 AM, Andrej Mitrovic
<andrej.mitrovich gmail.com> wrote:
 Does this mean assigning to fields won't be an option anymore when using =

 E.g.:

 class Foo
 {
 =A0 =A0int x;
 =A0 =A0int y;

 =A0 =A0void changeXY(int x, int y)
 =A0 =A0{
 =A0 =A0 =A0 =A0this.x =3D x;
 =A0 =A0 =A0 =A0this.y =3D y;
 =A0 =A0}
 }

 On Sun, Sep 5, 2010 at 6:09 PM, JMRyan <nospam nospam.com> wrote:
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote in
 news:i5rovm$1q4b$1 digitalmars.com:
 For classes this must be an rvalue.

 Andrei

I reported this as issue 4819.


Sep 05 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
++ on that bug report.

On a similar note, today I was rewriting a dsource class example
because I wanted to show that you can use "this.name" to assign to
fields that have the same name as a parameter. And then I accidentally
made this mistake when writing a different method:

class Foo
{
    string name;

    void printMe()
    {
        name = "test";
        writefln("printMe.name = %s, Foo.name = %s", name, this.name);
    }
}

The "name" in the printMe method was supossed to be the declaration
'string name = "test";'. But I forgot to put the type before name, and
inadvertently modified the class variable name. In this case I wasn't
even passing any parameters, so this is unfortunately impossible to
flag as an error because using "this" is optional in D.

On Mon, Sep 6, 2010 at 4:14 AM, bearophile <bearophileHUGS lycos.com> wrote:
 Andrei:
 If you can write (new Foo).x = x, then you can also write this.x = x. Try it
now!

See my bug reports/enhancement requests (about three days ago in a program of mine I have added a bug that enhancement 4407 is able to avoid): Arguments and attributes with the same name http://d.puremagic.com/issues/show_bug.cgi?id=3878 Bye, bearophile

Sep 05 2010
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Done. I only have 5 votes left though.

This is no democracy!! :p

On Mon, Sep 6, 2010 at 12:58 PM, bearophile <bearophileHUGS lycos.com> wrote:
 Andrej Mitrovic:
 ++ on that bug report.

Then vote for it :-) Bye, bearophile

Sep 06 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Friday 03 September 2010 13:22:51 JMRyan wrote:
 I wouldn't have thought of "this" representing an lvalue.  However, the
 following absurdity compiles and executes flawlessly.  Just don't
 uncomment the assignment to y.i!
 
 class Yikes
 {
     int i;
     this() { this = null; }
 }
 
 
 void main()
 {
     auto y = new Yikes();
     // y.i = 0;
 }
 
 Is this a bug in the compiler (v.2.047)?  Am I missing something in
 thinking it shouldn't be?

Of course, this is an lvalue. 1. Think about a struct for a moment, rather than a class. It's a value type. Assigning to this inside a struct would change the struct's value. In some circumstances, it would make perfect sense to do this. Assigning it to the struct's init property to reset it would be a prime example. 2. Think about what a member function _really_ looks like. The member function printM() in this class here class A { int _x; void printMe() { writeln(x); } } really looks like this void printMe(A this, printMe()) { writeln(this.x); } If you were to set this to null in printMe(), what would it do? Nothing. You just set a function parameter to null. Sure, after that, this be null _within that function_, but it shouldn't be null after that that because the actual object that this points to still exists, and when its reference gets passed to other member functions, those won't be null, because you just set the local variable to null. For instance, this program runs just fine: import std.stdio; class A { int _x; this(int x) { _x = x; } void print() { writeln(_x); } void nullifyMe() { this = null; } } void main() { auto a = new A(13); a.print(); a.nullifyMe(); a.print(); } It prints 13 13 Now, _your_ program bombs. However, I believe that that's because you assigned null to this in the _constructor_. My guess is that internally, your constructor looks something like this: Yikes this(Yikes this) { this = null; return this; } When this is called, its member variables (namely i) have been initialized, and its initial state is passed to the constructor to further do whatever stuff that you want your constructor to do. It then likely return null, which is what you get from new() and is what is assigned to your local variable y. So, y is then null. The Yikes object that you just created still exists. It's floating around in memory. It's just that you can't get at it. If you try this instead: import std.stdio; Yikes global; class Yikes { int i; this() { global = this; this = null; } } void main() { auto y = new Yikes(); global.i = 1; writeln(global.i); } it works and prints 1. You could even get rid of the "auto y = " part. So, this is most definitely an lvalue. It's a bit stupid to assign null to it - especially in the constructor - but it makes perfect sense that it works. And in some circumstances, it makes perfect sense to do so (though not with classes since all it would ever affect would be the local variable and any member functions that called from that member function). - Jonathan M Davis
Sep 03 2010
prev sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Friday 03 September 2010 14:38:27 Andrei Alexandrescu wrote:
 On 9/3/10 16:33 CDT, Jonathan M Davis wrote:
 Still, I don't know how you could make it a true rvalue.

It's very simple - make "this" the result of a hypothetical function call. Andrei

Ah, that would do it. Though you wouldn't want to _actually_ do that in the generated code given how poor the inliner is. - Jonathan M Davis
Sep 03 2010