the const correctness of the this pointer

[Sönke Ludwig]

Am 28.12.2009 21:46, schrieb Steven Schveighoffer:
> On Mon, 28 Dec 2009 15:18:21 -0500, Sönke Ludwig
> <ludwig_nospam at 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