On Mon, 28 Dec 2009 15:18:21 -0500, Sönke Ludwig
<[email protected]> 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
