Re: the const correctness of the this pointer

[Sönke Ludwig]

Am 28.12.2009 18:44, schrieb Denis Koroskin:
On Mon, 28 Dec 2009 03:02:23 +0300, TM <ith...@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