C# Language Design: explicit interface implementation of an event

Question

Small question about C# language design :))

If I had an interface like this:

interface IFoo {
  int Value { get; set; }
}

It's possible to explicitly implement such interface using C# 3.0 auto-implemented properties:

sealed class Foo : IFoo {
  int IFoo.Value { get; set; }
}

But if I had an event in the interface:

interface IFoo {
  event EventHandler Event;
}

And trying to explicitly implement it using field-like event:

sealed class Foo : IFoo {
  event EventHandler IFoo.Event;
}

I will get the following compiler error:

error CS0071: An explicit interface implementation of an event must use event accessor syntax

I think that field-like events is the some kind of dualism for auto-implemented properties.

So my question is: what is the design reason for such restriction done?

Answer 1

Interesting question. I did some poking around the language notes archive and I discovered that this decision was made on the 13th of October, 1999, but the notes do not give a justification for the decision.

Off the top of my head I don't see any theoretical or practical reason why we could not have field-like explicitly implemented events. Nor do I see any reason why we particularly need to. This may have to remain one of the mysteries of the unknown.

Answer 2

I guess it might have to do with the fact that you can't call an explicit interface implementation from other members of the class:

public interface I
{
    void DoIt();
}

public class C : I
{
    public C()
    {
        DoIt(); // error CS0103: The name 'DoIt' does not exist in the current context
    }

    void I.DoIt() { }
}

Note that you can call the method by upcasting to the interface first:((I)this).DoIt();. A bit ugly but it works.

If events could be explicitly implemented as ControlFlow (the OP) suggested, then how would you actually raise them? Consider:

public interface I
{
    event EventHandler SomethingHappened;
}

public class C : I
{
    public void OnSomethingHappened()
    {
        // Same problem as above
        SomethingHappened(this, EventArgs.Empty);
    }

    event EventHandler I.SomethingHappened;
}

Here you cannot even raise the event by upcasting to the interface first, because events can only be raised from within the implementing class. It therefore seems to make perfect sense to require accessor syntax for explicitly implemented events.

Answer 3

When explicitly implementing an event that was declared in an interface, you must use manually provide the add and remove event accessors that are typically provided by the compiler. The accessor code can connect the interface event to another event in your class or to its own delegate type.

For example, this will trigger error CS0071:

public delegate void MyEvent(object sender);

interface ITest
{
    event MyEvent Clicked;
}

class Test : Itest
{
    event MyEvent ITest.Clicked;  // CS0071
    public static void Main() { }
}

The correct way would be:

public delegate void MyEvent(object sender);

interface ITest
{
    event MyEvent Clicked;
}

class Test : Itest
{
    private MyEvent clicked;

    event MyEvent Itest.Clicked
    {
        add
        {
            clicked += value;
        }

        remove
        {
            clicked -= value;
        }
    }

    public static void Main() { }
}

see Compiler Error CS0071

Answer 4

This would not actually be an original thought by myself.

However, I thought I might respond to this:

"Off the top of my head I don't see any theoretical or practical reason why we could not have field-like explicitly implemented events. Nor do I see any reason why we particularly need to. This may have to remain one of the mysteries of the unknown." -Eric Lippert

---

In Chapter 23 of A Programmer's Introduction to C#, Second Edition, Eric Gunnerson wrote:

"[I]f another class also wanted to be called when the button was clicked, the += operator could be used, like this:

button.Click += new Button.ClickHandler(OtherMethodToCall);

Unfortunately, if the other class wasn't careful, it might do the following:

button.Click = new Button.ClickHandler(OtherMethodToCall);

This would be bad, as it would mean that our ButtonHandler would be unhooked and only the new method would be called."

...

"What is needed is some way of protecting the delegate field so that it is only accessed using += and -=."

---

He goes on over the next few pages to comment on including the add() and remove() methods to implement this behavior; being able to write to those methods directly and the consequence of storage allocation for unneeded delegate references.

I would add more, but I respect the author too much to do so without his permission. I recommend finding a copy of this book and would recommend anything by Eric Gunnerson in general (blog, etc...)

Anyway, I hope this is relevant to the topic and if so, hope it shines light on this "mystery of the unknown"? (I was reading this very chapter and searching Stack Overflow for insight into event handler logic considerations when creating custom collections from custom objects) - I only mention this because I claim no specific authority on this particular subject. I am merely a student in search of "enlightenment" myself :-)