www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - the const correctness of the this pointer

reply TM <ithink therefore.iam> writes:
Hello, 
I was dealing with delegates when I found that the const correctness of the
this pointer was 'lost' when accessing a member function of a class through a
temporary delegate. 

Here is an example:

class A{
    void f () {}
}

const A a = new A;
a.f() //error, this is normal.
auto g = &a.f;
g(); //no error. Is this normal ?

I may be wrong, but it seems to me that as the const property of the this
pointer is linked to the instance of the class (here 'a'), the delegate 'g'
should contain a const pointer to A (because 'a' is const).

More generally, I seems that there is no management of the const correctness of
the frame pointer of a delegate in D2

What about adding the const keyword for delegates, as we do for methods ? The
const property of the delegate's frame pointer would be part of its type.

Example: 

void f()
{
    int x;
    void g() const {
        x ++; //would produce an error since the type of g is [void delegate()
const]
   }
}

 
Any thoughts about this ?
Dec 27 2009
next sibling parent Jason House <jason.james.house gmail.com> writes:
TM Wrote:

 Hello, 
 I was dealing with delegates when I found that the const correctness of the
this pointer was 'lost' when accessing a member function of a class through a
temporary delegate. 
 
 Here is an example:
 
 class A{
     void f () {}
 }
 
 const A a = new A;
 a.f() //error, this is normal.
 auto g = &a.f;
 g(); //no error. Is this normal ?
 
 I may be wrong, but it seems to me that as the const property of the this
pointer is linked to the instance of the class (here 'a'), the delegate 'g'
should contain a const pointer to A (because 'a' is const).

Looks like something that should be entered into bugzilla
Dec 27 2009
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 27 Dec 2009 19:02:23 -0500, TM <ithink therefore.iam> wrote:

 Hello,
 I was dealing with delegates when I found that the const correctness of  
 the this pointer was 'lost' when accessing a member function of a class  
 through a temporary delegate.

 Here is an example:

 class A{
     void f () {}
 }

 const A a = new A;
 a.f() //error, this is normal.
 auto g = &a.f;
 g(); //no error. Is this normal ?

 I may be wrong, but it seems to me that as the const property of the  
 this pointer is linked to the instance of the class (here 'a'), the  
 delegate 'g' should contain a const pointer to A (because 'a' is const).

 More generally, I seems that there is no management of the const  
 correctness of the frame pointer of a delegate in D2

 What about adding the const keyword for delegates, as we do for methods  
 ? The const property of the delegate's frame pointer would be part of  
 its type.

 Example:

 void f()
 {
     int x;
     void g() const {
         x ++; //would produce an error since the type of g is [void  
 delegate() const]
    }
 }

 Any thoughts about this ?

This might be a difficult thing to fix, but it definitely *definitely* needs to be fixed. The problem is that a delegate stores a function pointer and a context pointer. However, it does not type the context pointer. For example, if you do this: import std.stdio; class A { void f() const {} } void main() { const A a = new A; a.f(); auto g = &a.f; writefln("%s", typeof(g).stringof); } You will get this: void delegate() The this pointer is hidden, and so is it's const decoration. I would expect to see: void delegate() const I'll file a bugzilla request for this. -Steve
Dec 28 2009
parent reply Jason House <jason.james.house gmail.com> writes:
Steven Schveighoffer Wrote:

 
 This might be a difficult thing to fix, but it definitely *definitely*  
 needs to be fixed.  The problem is that a delegate stores a function  
 pointer and a context pointer.  However, it does not type the context  
 pointer.  For example, if you do this:
 
 import std.stdio;
 
 class A
 {
      void f() const {}
 }
 
 void main()
 {
      const A a = new A;
      a.f();
      auto g = &a.f;
      writefln("%s", typeof(g).stringof);
 }
 
 You will get this:
 
 void delegate()
 
 The this pointer is hidden, and so is it's const decoration.  I would  
 expect to see:
 
 void delegate() const
 
 I'll file a bugzilla request for this.
 
 -Steve

I disagree. Once the delegate is passed off to some other region of code, why should that other code care that there's an object that might not get modified from using the delegate? Especially when you consider that which object or stack frame is not tracked by the type system. Pure delegates make sense to me though.
Dec 28 2009
parent reply TM <ithink therefore.iam> writes:
Jason House Wrote:

 Steven Schveighoffer Wrote:
 
 
 This might be a difficult thing to fix, but it definitely *definitely*  
 needs to be fixed.  The problem is that a delegate stores a function  
 pointer and a context pointer.  However, it does not type the context  
 pointer.  For example, if you do this:
 
 import std.stdio;
 
 class A
 {
      void f() const {}
 }
 
 void main()
 {
      const A a = new A;
      a.f();
      auto g = &a.f;
      writefln("%s", typeof(g).stringof);
 }
 
 You will get this:
 
 void delegate()
 
 The this pointer is hidden, and so is it's const decoration.  I would  
 expect to see:
 
 void delegate() const
 
 I'll file a bugzilla request for this.
 
 -Steve

I disagree. Once the delegate is passed off to some other region of code, why should that other code care that there's an object that might not get modified from using the delegate? Especially when you consider that which object or stack frame is not tracked by the type system. Pure delegates make sense to me though.

I disagree with you. To me, the loss of the frame pointer's const attribute looks like a cast. I do not expect to be allowed to call the above 'a.f' wihout casting a into a const A. And yet it is possible by using a delegate, which I think performs a hidden cast operation. I think Steven Schveighoffer is right. Moreover the const correctness of the this pointer is well managed as far as objects are concerned, so why not have the same behaviour with delegate ?
Dec 28 2009
parent reply Jason House <jason.james.house gmail.com> writes:
TM Wrote:

 Jason House Wrote:
 
 Steven Schveighoffer Wrote:
 
 
 This might be a difficult thing to fix, but it definitely *definitely*  
 needs to be fixed.  The problem is that a delegate stores a function  
 pointer and a context pointer.  However, it does not type the context  
 pointer.  For example, if you do this:
 
 import std.stdio;
 
 class A
 {
      void f() const {}
 }
 
 void main()
 {
      const A a = new A;
      a.f();
      auto g = &a.f;
      writefln("%s", typeof(g).stringof);
 }
 
 You will get this:
 
 void delegate()
 
 The this pointer is hidden, and so is it's const decoration.  I would  
 expect to see:
 
 void delegate() const
 
 I'll file a bugzilla request for this.
 
 -Steve

I disagree. Once the delegate is passed off to some other region of code, why should that other code care that there's an object that might not get modified from using the delegate? Especially when you consider that which object or stack frame is not tracked by the type system. Pure delegates make sense to me though.

I disagree with you. To me, the loss of the frame pointer's const attribute looks like a cast.

The quoted code (by Steve) above is not the same as yours. Both the variable and the called member are const. Invoking the delegate does not violate the const system. I did respond to your original example saying to file a bugzilla entry.
 I do not expect to be allowed to call the above 'a.f' wihout casting a into a
const A. And yet it is possible by using a delegate, which I think performs a
hidden cast operation.
 

Calling a const member function is allowed without casting from either thread-local mutable data or immutable data. Calling a non-const member function on a const object is what's illegal. That's what your original sample did. Constructing such a delegate (without casts) should be illegal and is a bug in dmd. Once a const-correct delegate is created, it should be usable like any other delegate.
Dec 28 2009
parent TM <ithink therefore.iam> writes:
Jason House Wrote:

 TM Wrote:
 
 Jason House Wrote:
 
 Steven Schveighoffer Wrote:
 
 
 This might be a difficult thing to fix, but it definitely *definitely*  
 needs to be fixed.  The problem is that a delegate stores a function  
 pointer and a context pointer.  However, it does not type the context  
 pointer.  For example, if you do this:
 
 import std.stdio;
 
 class A
 {
      void f() const {}
 }
 
 void main()
 {
      const A a = new A;
      a.f();
      auto g = &a.f;
      writefln("%s", typeof(g).stringof);
 }
 
 You will get this:
 
 void delegate()
 
 The this pointer is hidden, and so is it's const decoration.  I would  
 expect to see:
 
 void delegate() const
 
 I'll file a bugzilla request for this.
 
 -Steve

I disagree. Once the delegate is passed off to some other region of code, why should that other code care that there's an object that might not get modified from using the delegate? Especially when you consider that which object or stack frame is not tracked by the type system. Pure delegates make sense to me though.

I disagree with you. To me, the loss of the frame pointer's const attribute looks like a cast.

The quoted code (by Steve) above is not the same as yours. Both the variable and the called member are const. Invoking the delegate does not violate the const system. I did respond to your original example saying to file a bugzilla entry.
 I do not expect to be allowed to call the above 'a.f' wihout casting a into a
const A. And yet it is possible by using a delegate, which I think performs a
hidden cast operation.
 

Calling a const member function is allowed without casting from either thread-local mutable data or immutable data. Calling a non-const member function on a const object is what's illegal. That's what your original sample did. Constructing such a delegate (without casts) should be illegal and is a bug in dmd. Once a const-correct delegate is created, it should be usable like any other delegate.

I totally agree that the problem is the conversion of a [ void delegate() const] to a [void delegate()]. I totally agree that we should be allowed to call the const-correct delegate once it has been created. ie, this should be correct: void delegate() g = cast ( void delegate() ) (f); //here a cast would be necessary g(); //This would be OK, of course Concerning the bugzilla, the problem is that adding the 'const' and 'share' properties of the frame pointer as a part of the delegate's type is more like a new feature than a compiler bug, isn't it ? On the other hand, it looks like we all agree to say this is a must have feature. Do wee ?
Dec 28 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 28 Dec 2009 10:50:02 -0500, Jason House  
<jason.james.house gmail.com> wrote:

 Steven Schveighoffer Wrote:

 This might be a difficult thing to fix, but it definitely *definitely*
 needs to be fixed.  The problem is that a delegate stores a function
 pointer and a context pointer.  However, it does not type the context
 pointer.  For example, if you do this:

 import std.stdio;

 class A
 {
      void f() const {}
 }

 void main()
 {
      const A a = new A;
      a.f();
      auto g = &a.f;
      writefln("%s", typeof(g).stringof);
 }

 You will get this:

 void delegate()

 The this pointer is hidden, and so is it's const decoration.  I would
 expect to see:

 void delegate() const

 I'll file a bugzilla request for this.

 -Steve

I disagree. Once the delegate is passed off to some other region of code, why should that other code care that there's an object that might not get modified from using the delegate? Especially when you consider that which object or stack frame is not tracked by the type system. Pure delegates make sense to me though.

It could be part of the interface for a function that takes a delegate (i.e. I require that this delegate does not modify it's 'this' parameter). But I agree, there could be issues -- if you don't care what the delegate does (const or not), then how do you specify that? I suppose we need delegate contravariance at that point -- a delegate to a const function should implicitly casts to a delegate of a non-const function. See http://d.puremagic.com/issues/show_bug.cgi?id=3075 This might be a good reason to revive that enhancement. BTW, you also need to correctly mark shared functions, which *do* matter as far as delegates go, since you need to synchronize access to the 'this' pointer before calling the delegate. -Steve
Dec 28 2009
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 28 Dec 2009 03:02:23 +0300, TM <ithink therefore.iam> wrote:

 Hello,
 I was dealing with delegates when I found that the const correctness of  
 the this pointer was 'lost' when accessing a member function of a class  
 through a temporary delegate.

 Here is an example:

 class A{
     void f () {}
 }

 const A a = new A;
 a.f() //error, this is normal.
 auto g = &a.f;
 g(); //no error. Is this normal ?

 I may be wrong, but it seems to me that as the const property of the  
 this pointer is linked to the instance of the class (here 'a'), the  
 delegate 'g' should contain a const pointer to A (because 'a' is const).

 More generally, I seems that there is no management of the const  
 correctness of the frame pointer of a delegate in D2

 What about adding the const keyword for delegates, as we do for methods  
 ? The const property of the delegate's frame pointer would be part of  
 its type.

 Example:

 void f()
 {
     int x;
     void g() const {
         x ++; //would produce an error since the type of g is [void  
 delegate() const]
    }
 }

 Any thoughts about this ?

It shouldn't compile: it makes no sense to can't non-const method through const reference, and the same applies to shared. OTOH, the following should just work: class A { void constMethod() const {} void sharedMethod() shared {} } const A a1 = new A(); void delegate() const dg1 = &a1.constMethod; shared A a2 = new shared A(); void delegate() shared dg2 = &a2.sharedMethod(); (in examples above, const and shared attributes are applied to both function pointer and frame pointer) I already wrote about a necessity of introduction of "shared delegates" in a separate thread. Until then, Thread creation is broken in D.
Dec 28 2009
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= writes:
Am 28.12.2009 18:44, schrieb Denis Koroskin:
 On Mon, 28 Dec 2009 03:02:23 +0300, TM <ithink therefore.iam> wrote:

 Hello,
 I was dealing with delegates when I found that the const correctness
 of the this pointer was 'lost' when accessing a member function of a
 class through a temporary delegate.

 Here is an example:

 class A{
 void f () {}
 }

 const A a = new A;
 a.f() //error, this is normal.
 auto g = &a.f;
 g(); //no error. Is this normal ?

 I may be wrong, but it seems to me that as the const property of the
 this pointer is linked to the instance of the class (here 'a'), the
 delegate 'g' should contain a const pointer to A (because 'a' is const).

 More generally, I seems that there is no management of the const
 correctness of the frame pointer of a delegate in D2

 What about adding the const keyword for delegates, as we do for
 methods ? The const property of the delegate's frame pointer would be
 part of its type.

 Example:

 void f()
 {
 int x;
 void g() const {
 x ++; //would produce an error since the type of g is [void delegate()
 const]
 }
 }

 Any thoughts about this ?

It shouldn't compile: it makes no sense to can't non-const method through const reference, and the same applies to shared. OTOH, the following should just work: class A { void constMethod() const {} void sharedMethod() shared {} } const A a1 = new A(); void delegate() const dg1 = &a1.constMethod; shared A a2 = new shared A(); void delegate() shared dg2 = &a2.sharedMethod(); (in examples above, const and shared attributes are applied to both function pointer and frame pointer) I already wrote about a necessity of introduction of "shared delegates" in a separate thread. Until then, Thread creation is broken in D.

Actually in both cases the error is not happening when the delegate is called but at the point where the delegate is created. _Creating_ a delegate to a non-const function should simply be impossible when a const object is bound (result in a compile time error). Similarily, for a shared object, the necessary synchronization code should be added to the delegate instead of having the shared attribute attached to the delegate. Typing the delegate will just create superfluous type combinations and complicate delegate usage - additionally it would be strange in the sense that it makes assumptions about the type of the "context pointer" without knowing what it is (object, stack frame, struct, ...). Sönke
Dec 28 2009
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= writes:
Am 28.12.2009 21:46, schrieb Steven Schveighoffer:
 On Mon, 28 Dec 2009 15:18:21 -0500, Sönke Ludwig
 <ludwig_nospam informatik.uni-luebeck.de> wrote:


 Actually in both cases the error is not happening when the delegate is
 called but at the point where the delegate is created. _Creating_ a
 delegate to a non-const function should simply be impossible when a
 const object is bound (result in a compile time error). Similarily,
 for a shared object, the necessary synchronization code should be
 added to the delegate instead of having the shared attribute attached
 to the delegate.

 Typing the delegate will just create superfluous type combinations and
 complicate delegate usage - additionally it would be strange in the
 sense that it makes assumptions about the type of the "context
 pointer" without knowing what it is (object, stack frame, struct, ...).

I'd agree that the typechecking for const (and immutable) can be done on the point of delegate creation, especially since one of the perks of delegates is you don't have to tell the compiler what type the context pointer is already. However, shared is a different story, since the calling convention is different. I think we need shared delegates as Denis said. They would be different types than normal delegates. What you are proposing is that every shared function that you wish to take a delegate of has a "wrapper" function also implemented which does the shared synchronization and then calls the underlying function, just so it looks like a normal delegate. I'd rather see the compiler simply treat shared delegates as different types than normal delegates, and insert the synchronization code before calling the delegate. With such delegates, you could easily make a shared delegate wrapper type that did exactly what you wanted anyways. It appears that delegate contravariance isn't required here after all (unfortunately), but we definitely need shared delegates. -Steve

I agree on what you say about shared. My thought was just that maybe there is actually no place where you would ever declare a function which gets a shared delegate, because normally it does not matter for the caller on what kind of thing a delegate is called. Seen that way, an implicit non-shared wrapper would be a helpful feature for the 99% case. Of course, having shared delegates would never hurt (maybe for some class internal use?). Sönke
Jan 02 2010
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 28 Dec 2009 15:18:21 -0500, Sönke Ludwig  
<ludwig_nospam informatik.uni-luebeck.de> wrote:


 Actually in both cases the error is not happening when the delegate is  
 called but at the point where the delegate is created. _Creating_ a  
 delegate to a non-const function should simply be impossible when a  
 const object is bound (result in a compile time error). Similarily, for  
 a shared object, the necessary synchronization code should be added to  
 the delegate instead of having the shared attribute attached to the  
 delegate.

 Typing the delegate will just create superfluous type combinations and  
 complicate delegate usage - additionally it would be strange in the  
 sense that it makes assumptions about the type of the "context pointer"  
 without knowing what it is (object, stack frame, struct, ...).

I'd agree that the typechecking for const (and immutable) can be done on the point of delegate creation, especially since one of the perks of delegates is you don't have to tell the compiler what type the context pointer is already. However, shared is a different story, since the calling convention is different. I think we need shared delegates as Denis said. They would be different types than normal delegates. What you are proposing is that every shared function that you wish to take a delegate of has a "wrapper" function also implemented which does the shared synchronization and then calls the underlying function, just so it looks like a normal delegate. I'd rather see the compiler simply treat shared delegates as different types than normal delegates, and insert the synchronization code before calling the delegate. With such delegates, you could easily make a shared delegate wrapper type that did exactly what you wanted anyways. It appears that delegate contravariance isn't required here after all (unfortunately), but we definitely need shared delegates. -Steve
Dec 28 2009