Yesterday, at PDC in Redmond, Anders introduced the world to C# “v.Next,” which has first class language support for asynchronous user code. It’s exciting, and I’m sure it will have a huge impact on developers. I have been somewhat less involved with that part of the team, mostly only acting as an advisor on the compiler implementation. That’s because I have been working on the last bit in Anders’ talk, which he calls “Compiler as a Service.” It’s going quite well and I am very much looking forward to the day when Microsoft can share more about this technology and get it into use. You’re going to love it.

However, when that day comes I will not be here. Today is my last day at Microsoft. I will be pursuing my career in what I can only hope will be pastures as green as this one. The C# team is amazing, the technology is amazing, and this is the best job I’ve ever had. But sometimes you need to try something new.

I have but one regret, and that is that I chose to host my blog on a property that is controlled and maintained by Microsoft. This means the blog ends here. However, I’ll pick it up elsewhere, and I hope you’ll join me. Thanks!

https://www.chrisburrows.net/

using System;
using System.Dynamic;

class MyDynamicObject : DynamicObject
{
    public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, out object result)
    {
        Console.WriteLine("You called method {0}!", binder.Name);
        Console.WriteLine("... and passed {0} args.", args.Length);
        result = null;
        return true;
    }
}

class Program
{
    static void Main(string[] args)
    {
        dynamic d = new MyDynamicObject();
        d.Foo(d, 1, "bar");
    }
}

... that prints:

You called method Foo!
... and passed 3 args.

That’s all well and good. But I want to tell you that although this works and is easy, DynamicObject is not a type that is specially known to the DLR, and that this is not the primary mechanism to define dynamic objects. The primary mechanism is to implement the interface IDynamicMetaObjectProvider, and to provide your own specialization of DynamicMetaObject. These two types are specially known to the DLR and they are the mechanism by which dynamic (including DynamicObject) really works. DynamicObject is a tool of convenience. You could write it yourself, if you wanted to. The design of DynamicObject deliberately introduces some trade-offs in the name of ease-of-use, and if your code or library is not OK with those trade-offs, then you should consider your alternatives.

Binding vs. executing

One thing that DynamicObject does to your dynamic objects is that it confuses two separate “phases” of the execution of a dynamic operation. There is a lot of machinery in the DLR that is designed to make your dynamic operations fast, and there are concepts called “call sites” and “rules” and “binders,” etc., and you can dig into this yourself if it’s important, but the upshot is: when a dynamic operation is bound at runtime, the binding is cached using something called a “rule” that indicates the circumstances under which to execute some code, as well as the code to execute. Subsequent to the binding, the code the binding produced is simply run when needed.

If you implement your dynamic object using DynamicObject, these things still happen. However, they ignore the code that you put in your DynamicObject and execute it every time through a true dynamic operation. Let me give you an example to make this a little clearer.

Suppose you wanted to write a dynamic type that queried some external data somewhere. With DynamicObject, you might do something like the following:

class MyDynamicData : DynamicObject
{
    public override bool TryGetMember(GetMemberBinder binder, out object result)
    {
        string propName = binder.Name;

        if (this.externalData.HasColumn(propName))
        {
            result = this.externalData.GetData(this.currentRow, propName);
            return true;
        }
        else
        {
            return base.TryGetMember(binder, out result);
        }
    }
    // ...
}

In this code, we're trying to get a property value. So we go to the external data to see if the property name makes sense, and then we retrieve the relevant data to return to the user. Remember I said that dynamic bindings use “rules?” If the user types “d.FooBaz”, where d holds one of these MyDynamicData objects, then “rule” that is generated is as follows. First, the test part is this:

($arg0 TypeEqual MyDynamicData)

And the execution part is this:

.Block(System.Object $var1) {
    .If (
        .Call ((System.Dynamic.DynamicObject)$$arg0).TryGetMember(
            .Constant<System.Dynamic.GetMemberBinder>(Microsoft.CSharp.RuntimeBinder.CSharpGetMemberBinder),
            $var1)
    ) {
        $var1
    } .Else {
        .Throw .New Microsoft.CSharp.RuntimeBinder.RuntimeBinderException("'MyDynamicData' does not contain a definition for 'FooBaz'")
    }
}

If that syntax doesn’t make much sense to you, let me explain. The DLR encodes these things using LINQ expression trees, and the strings above are simply a debug view of those things. They’re not complicated. Basically, the rule says that if the actual runtime type of the object is a MyDynamicData, then what the DLR should execute is the code below, which calls your TryGetMember, and if that returns true then return your result. Otherwise, it should throw an exception that says there is no property FooBaz. That exception, incidentally, came from the C# binder. The whole dance that goes on to determine what the rule is is a little bit complicated, but the important part is that the TryGetMember you defined in your MyDynamicData is not a part of it. Instead, every single time that user’s line of code that contains “d.FooBaz” runs, your TryGetMember is run. Every time.

You could imagine an alternative, where instead, of TryGetMember running every time, you write some code that looks at the name of the property and makes a determination about what it should do, and then the rule contains code that simply does that thing. In our case, the rule would just have to run the “this.externalData.GetData(this.currentRow, propName)” part. Or just throw if the property name was bogus. Either way, you’re doing less every time through. Of course, this alternative exists, and it requires you not to use DynamicObject. If you implemented your own IDynamicMetaObjectProvider, you could slim up your rules as much as possible by doing your analysis once, not on every execution.

Object is king--except DynamicObject

There is another snag in DynamicObject that is in place in the interest of speed and ease-of-use, and it is the following: when the call site’s underlying language provides some binding for any operation, that binding overrules any dynamic bindings that might exist. This is in contrast to the ordinary behavior in the DLR, which is that the object gets to pick what it wants to do first. That strategy is sometimes summarized by the DLR’s designers as “object is king.” And, well, DynamicObject in some sense adheres to this principle, except that what it decides to do is defer to the language whenever it can.

This has some interesting consequences in C#. Check out the following program.

using System;
using System.Collections;
using System.Dynamic;

class MyDynamicObject : DynamicObject
{
    public override bool TryBinaryOperation(BinaryOperationBinder binder, object arg, out object result)
    {
        Console.WriteLine("TryBinaryOperation for {0}", binder.Operation);
        result = "dynamically returned result";
        return true;
    }

    public override bool TryConvert(ConvertBinder binder, out object result)
    {
        Console.WriteLine("TryConvert for {0}", binder.Type.Name);
        result = new string[] { "dynamically", "returned", "result" };
        return true;
    }
}

class QuestionableProgram
{
    static void Main(string[] args)
    {
        dynamic d = new MyDynamicObject();
        Console.WriteLine(d == null);
        Console.WriteLine((IEnumerable)d);
    }
}

What does this do? You might like to think that it prints the strings in the DynamicObject method overrides. But it does not. It prints “False” and then throws. Why? Because when the DynamicObject was asked to bind itself, it first asked the C# binder to bind the operations. In the first case, “d == null”, the C# binder said “yes! I can bind this! here you go!” and returned a normal object identity comparison. In the second case, the C# binder said “yes! I can bind this! here you go!” and returned a normal interface reference coercion. For that last one, recall that there is always an explicit conversion from most class types to any interface type in C# (6.2.4, bullet 3), though they can fail. And fail this one does, since MyDynamicObject does not statically implement IEnumerable.

Just to expand on the interface conversion example a bit, it’s especially weird since if the conversion were implicit (say, try assigning to a local), then the dynamic conversion would have worked. Why? Because the C# binder would have said, “nope! no implicit conversion to IEnumerable,” and then the DynamicObject implementation would have let TryConvert do its thing.

And these are just some of the examples. This behavior means that you cannot dynamically do lots of things, include define a ToString or Equals method, or even hide such members as TryInvokeMember. In other words, if I have a DynamicObject in hand and concealed behind the dynamic type, all of the overrideable members are always directly (though dynamically) invocable. Ugh.

Again, if this behavior does not suit you, then you need to roll your own.

But there’s a reason

I don’t mean to disparage DynamicObject. It really is a convenient and easy-to-use type, and if you’re not exposing dynamic objects in a library then it may be perfectly suitable to use.

The design decisions that led us here are deliberate. First, for the intermingling of binding and execution code, well, that whole protocol is very confusing. DynamicObject presents a much more easy to understand model. It doesn’t even require you to understand LINQ expression trees. But it gives up performance. Then, binding statically when possible gets a lot of that performance back. To give an example, although you cannot directly dynamically expose all the things I mentioned in the last bit (==, interface conversions, etc), you can just as easily introduce them statically and they’ll get called with no further help from you, and more quickly too.

ExpandoObject, by the way, is the other convenience type for users of static languages such as C# to create dynamic objects. You can read about both of these types, if you are interested, in the DLR’s excellent documentation at https://dlr.codeplex.com/.

Just remember that when someone says that “DynamicObject is the way to generate dynamic types in C#,” what they should really have said is that DynamicObject is a way to generate dynamic types in C#. Other ways include directly with IDynamicMetaObjectProvider, or by stepping outside of C# and defining some types in Python or Ruby or any other DLR language. I intended to present some of these alternatives in the future.

Some background

In .NET, arrays of reference types are covariant in their element type, but not safely. Eric, as always, has a post that goes into this more deeply if you want to refresh your memory. The upshot is that if you have a Derived[], you can convert it to a Base[] and use it that way. For instance,

class Base { }
class Derived : Base { }
 
class Program
{
    static void Main()
    {
        Derived[] derivedArray = new Derived[10];
        // This is the covariant conversion
        Base[] baseArray = derivedArray;
 
        for (int i = 0; i < baseArray.Length; ++i)
        {
            // Putting a Derived into our Base[] is ordinary polymorphism
            baseArray[i] = new Derived();
        }
    }
}

Allowing this conversion from Derived[] to Base[] is not safe because now the compiler can’t help you know if your types match up when you set array elements. In the preceding example, I can put the Derived in the array, but imagine if I had another unrelated derived class, OtherDerived. Putting those things in the array must fail, since the actual array can contain only Deriveds, and OtherDeriveds are not Deriveds. In Eric’s perhaps more folksy example, “you can’t put a Turtle into an array of Giraffes.”

class Base { }
class Derived : Base { }
class OtherDerived : Base { }
 
class Program
{
    static void Main()
    {
        Derived[] derivedArray = new Derived[10];
        // This is the covariant conversion
        Base[] baseArray = derivedArray;
 
        for (int i = 0; i < baseArray.Length; ++i)
        {
            // Putting a OtherDerived into our Base[] is ordinary
            // polymorphism. However, this is going to cause a runtime
            // exception because the actual array won't be able to
            // store an OtherDerived.
            baseArray[i] = new OtherDerived();
            // Unhandled Exception: System.ArrayTypeMismatchException: 
            //   Attempted to access an element as a type incompatible
            // with the array.
        }
    }
}

Well now to the point I want to address: where did that exception come from? It came from the runtime, which was in a unique position to know what the real type of the array object was, and the real type of the element. It needed to determine if the assignment was allowable and throw if not. Now if you think about this for a minute, you can see that it’s going to have to perform that check for every assignment to an array element, right? The compiler just can’t know if any assignment to a covariant array is ever going to work, and the runtime is always going to have to be there to manage the potential for failure. Can we turn that off? Does it make sense to? What does the check cost you?

A workaround

Well, if it’s doing that check for every assignment to an array, that’s probably going to cost you something. Let’s see if we can get rid of the check to determine what the cost is. Remember I said that arrays are covariant only for reference types? We’re going to use that information. If we have an array of value types, the runtime isn’t going to have to perform that check anymore, since it knows that the IL the compiler emitted wasn’t going to allow assignment of anything but that value type to that array.

So if I want to have an array of reference types, but get the runtime to treat it like an array of value types, what have I got to do? Just wrap the reference type in a value type. There you go. That’s the trick. Let’s see what that does.

I’m going to create a simple value type that merely holds a reference. I am even going to make it generic. And to make this as dead-simple as I can, that’s all I’ll do. You could imagine a potentially easier-to-use version of this code that has implicit conversions and nice constructors, but let’s not do any of that.

struct Reference<T> where T : class
{
    public T Value;
}

Ok, so, wow, what is that thing? It’s no bigger than the reference we started with. And if I want to make an array of them in order to get rid of covariance, I can. And here’s how I’d use it.

class Base { }
class Derived : Base { }
 
class Program
{
    static void Main()
    {
        Reference<Base>[] baseArray = new Reference<Base>[10];
 
        for (int i = 0; i < baseArray.Length; ++i)
        {
            baseArray[i] = new Reference<Base> { Value = new Derived() };
        }
    }
}

Now I have an array assignment that doesn’t need the runtime to perform a check anymore, and the reason is because it’s impossible for there to be anything in “baseArray” except for an array of the exact type I said. The struct-ness of Reference<T> prevents the possibility of anyone having performed a covariant conversion as existed in our previous examples. So I got rid of that check, right? But I added the initialization of a value type. Did I win or lose? Let’s do some timing to figure it out.

The experiment

Here’s my code. I’m going to time two different things: First, I’ll put a lot of Deriveds into a Base[], and then I’ll put a lot of Reference<Base>s that hold Deriveds into a Reference<Base>. I’m using huge arrays just because I want to prove to myself that the jitter isn’t going to lift some of these operations out of the loop. And I’m producing Release binaries that will run on the 32-bit framework on my 64-bit machine. I’ll time each example a few times to be sure. Here’s the code.

class Base { }
class Derived : Base { }
 
struct Reference<T> where T : class
{
    public T Value;
}
 
class Program
{
    const int Count = 1 << 27;
 
    static void Main()
    {
        Stopwatch watch = new Stopwatch();
 
        TestReferenceArray(watch);
        TestReferenceArray(watch);
        TestReferenceArray(watch);
 
        TestValueArray(watch);
        TestValueArray(watch);
        TestValueArray(watch);
    }
 
    static Base[] TestReferenceArray(Stopwatch watch)
    {
        Base[] array = new Base[Count];
        var element = new Derived();
 
        watch.Restart();
        for (int i = 0; i < Count; ++i)
        {
            array[i] = element;
        }
        watch.Stop();
        Console.WriteLine(watch.ElapsedMilliseconds);
 
        return array;
    }
 
    static Reference<Base>[] TestValueArray(Stopwatch watch)
    {
        Reference<Base>[] array = new Reference<Base>[Count];
        var element = new Derived();
 
        watch.Restart();
        for (int i = 0; i < Count; ++i)
        {
            array[i] = new Reference<Base> { Value = element };
        }
        watch.Stop();
        Console.WriteLine(watch.ElapsedMilliseconds);
 
        return array;
    }
}

Have a seat. Here’s what it prints out.

2507
2471
2474
595
607
593

Wow! That’s a huge time difference, and a big win. It’s FOUR TIME FASTER! I wouldn’t blame you for thinking that you have to go to your code base right now and eliminate arrays of reference types from it; but hold on a second. That’s not the whole story.

Issue #1: Are the types exact?

In the example that I timed, I was putting a Derived into arrays with element type Base. The types weren’t the same, and therefore the check that the runtime performed had to be complicated by doing something like walking an inheritance hierarchy. But what if I were putting Bases into the Base array. What do the times look like then? (I won’t replicate the code here; just replace “new Derived()” with “new Base()” everywhere).

805
775
771
593
593
599

Oh, that’s much more reasonable. The lesson here is that for my scenario, if I’m not making use of polymorphism, I have much less to be worried about.

Issue #2: Which runtime exactly?

I said that I was doing tests on the 32-bit framework on my 64-bit machine. I ensured that by building my binaries “x86,” which is the default for VS2010. What if I instead build them “Any CPU” so that I can run the test on the 64-bit framework? Under those conditions, I am swapping out the whole stack that my tests run on for a whole different runtime. Let’s see what the numbers are then.

2102
2057
2055
789
784
784

Ok, still faster, but not by as big a factor. What about for the exact type case?

861
848
846
792
790
817

Nearly the same! So my example seems to be not as big a deal for 64-bit processes. I am not sure why. There is another oddity here that I can’t explain: when I build Debug binaries, the Reference<T> trick makes my example about three times SLOWER. I have no idea why.

Issue #3: My example is not your scenario

I tried to make the thing I was timing as simple as possible. But I’m using relatively a lot of array assignments. Do you do that much? Probably not. I’m not doing any I/O and not waiting on any user interaction, are you? I also have a giant array and I’m clearly blowing out the CPU cache in my for loops. Does your code do that? I’m assigning arrays in a tight loop with a known upper bound. Are you? Does the jitter lift the bounds checking out of the loop, and how would that check compare with the assignment compatibility check?

My point is that as with any performance timing, there are a lot of variables and a lot of considerations. If you want to make your program perform better using this trick, you need to try it and then time it yourself. I am not saying that .NET arrays are slower than they need to be or unsuited for your application. But it’s a fun experiment to try; how many milliseconds faster can you make your scenario, and is it worth the cost? Were you using the covariance of arrays in your code, and therefore ineligible to even consider this trick?

Why?

Why does C# have these unsafe covariant arrays to begin with? I was not here at the time, but I can confidently say that the CLR needed them because they needed to support languages that have array covariance. One example of such a language (in fact, probably the interesting example) is Java. C# has them both because the CLR has them and because it was a clear goal to that if users were porting existing code to C#, they were met with as few hurdles as possible. Also, there would have been complications with supporting both covariant arrays and invariant arrays in the same runtime; imagine the confusion users and compiler-writers would face trying to interop between the two. The language design notes from 1999 bear out these claims.

• June 1: San Diego
• June 2: Orange County
• June 3: LA County

I'm excited to be able to talk about some topics that I find very interesting and work that I'm proud of. I'm excited to meet some California users. I'm eager to get my hands on some good Mexican food. And I'm grateful for the work various organizers have put into getting this together. If you have any interest in C# in general or C# 4 in particular, please come out and say hi!

https://www.microsoft.com/express/downloads/

You can also download trial versions of the full Visual Studio SKUs from here:

https://www.microsoft.com/visualstudio/en-us/download

MSDN’s main page is covered in purple and full of more links than you have time to click on, so you can check out everything there too.

The C# compiler and the support for dynamic, including the DLR, come in the box on every distribution of the .NET Framework 4.0. And also, of course, with every edition of Visual Studio. In addition to that, you’re going to want to use C# dynamic with some good dynamic languages. Happily, IronPython has released a final version (2.6.1) built for use with .NET 4.0. Check it out!

https://ironpython.codeplex.com/

Thanks!

UPDATE: It wasn’t up when I posted this, but now IronRuby has also pushed a final build (1.0) that runs on top of the released .NET 4.0!

https://ironruby.codeplex.com/

And so it is with dynamic. Shortly after PDC ’08, I posted a number of things that were correct and well-thought-out. At the time. They are now incorrect, and I want to draw attention to that fact so everyone has the right idea about how this all works. Or, at least, not the wrong idea. Well, actually, if you have the wrong idea I don’t want the blame.

In my original series on dynamic, Part IV, Part V, and Part VI are wrong. I touched up Part IV at the end, but V and VI are too wrong to fix. Here’s why.

Overload resolution with dynamic

We had this big complicated scheme thought out: overload resolution would respect dynamic arguments and bind statically sometimes, but mostly it would go dynamic. There was something called the phantom method. The idea was that you could write an API with methods that would always be statically bound, and then treat your parameters as dynamic in the method body.

None of that survives. It was too complicated. The new rules are dead simple: If you have a method call with a dynamic argument, it is dispatched dynamically, period. During the runtime binding, all the static types of your arguments are known, and types are picked for the dynamic arguments based on their actual values.

See? That’s much simpler to explain, and easier to reason about. It means that in the following code, the call to M will be dispatched at runtime, and the M that gets picked will depend on the value in d. In this case, M(string) will be called.

class C
{
    void M(dynamic d) { }
    void M(string s) { }
    void M(int i) { }

    void CallM()
    {
        dynamic d = "test";
        this.M(d);
    }
}

You might ask, what about that M(dynamic) overload? Well, when you have a parameter of type dynamic, the fact that it is dynamic is only relevant in the body of the method. Because of this new simple scheme for overload resolution, as callers see it, M(dynamic) is really no different than M(object).

Assignment conversions

I made a big fuss about something called assignment conversions. These were in the design for a while, and they were a way for us to dispatch conversions dynamically without introducing unnecessary loops in the conversion graph. Well, the idea was right, but the abstraction we settled on is different. And I have to admit it’s a little clever.

The rules for conversions involving dynamic are now as follows:

1. There is an implicit conversion to dynamic from every type (modulo the weirdos, like pointer types). Basically, if it has an implicit conversion to object, it has an implicit conversion to dynamic too. This has not changed.
2. There are no implicit conversions from dynamic to any type aside from itself and object.
3. However (this is the clever part), there are implicit conversions from any dynamic expression (not type!) to any type.
4. There are implicit conversions between types (in both directions) when they differ only by object and dynamic (as in the exception in rule 2).

Let’s consider the consequences of rules number 2 and 3. Why the distinction between conversions of expressions and conversions of types? Well, for one thing, it allows us to do what “assignment conversions” used to do. In particular, if you have an assignment from a dynamic d:

string s = d;

Then the conversion exists because of rule 3. The conversion is from the expression d and not the type dynamic. This is true for most places where you have a dynamic value, including returns and foreaches and property sets, and everything I laid out in Part V of the dynamic series.

So how do we observe that there exists no conversion from the type dynamic to the type string? Easy, we just need a part of the language that only uses types (without values). Enter method type inference! I can use covariance to prove to you that the compiler does not allow conversions from dynamic to string:

public class Program
{
    static void Main()
    {
        IEnumerable<dynamic> ied = null;
        IEnumerable<string> iei = null;

        var x = M(ied, iei);
        x.ThisisOnlyCompilesIfXIsDynamic();
    }

    static T M<T>(IEnumerable<T> x, IEnumerable<T> y) { return default(T); }
}

Ok, this program compiles, and therefore method type inference must have selected dynamic for T in the method type inference step while performing overload resolution in the call to M. In short, the line of reasoning here is:

1. The first argument has type IEnumerable<dynamic>, and therefore dynamic is a candidate for T (and a lower bound).
2. The second argument has type IEnumerable<string>, and therefore string is a candidate for T (and a lower bound).
3. When fixing T among the set of candidates { dynamic, string }, since there is a conversion from string to dynamic, but not the other way around, the more general type (dynamic) is selected.

In step 3, if there were a conversion back again from dynamic to string, then neither type would be more general, and method type inference would have failed with an ambiguity. Thus, I’ve proven to you that that conversion must not exist.

Note: I had to use covariance and stick these types into an IEnumerable (I could have used arrays too) because if one of the arguments had been “naked” dynamic, then the whole analysis would have been deferred to runtime due to the new overload resolution rules. In this example, M is dispatched statically.

Note 2: The compiler contains a slight deviation from the language spec on rule #2 above. During method type inference, the compiler believes that the only implicit conversion from the type dynamic is to dynamic. This is a vestige of the previous implementation that was discovered too late to fix. You will only be able to observe it in scenarios such as the above example, where you replace “string” with “object”. Such code should give an ambiguity, but instead picks dynamic. I don’t expect anyone to spend much time fretting about this.

Other things

There have been a number of changes to the DLR, notably the names of many of their types, but also in the design of binders. These affected Part II, so I updated the code samples so that they now compile and run.

In conclusion

When I was posting in 2008, the design was going through a lot of change. In fact, the reason I stopped posting about dynamic is because of these changes; I knew I was going to ultimately be wrong because everything was moving around so much. Incidentally, this made my day job a bit hectic too, as I was implementing a moving target.

Now, however, it’s too late to change anything, and I can speak with confidence about what C# 4 will look like when it launches.

As with any list of recommendations someone gives you for your source code, please feel free to adapt them or ignore them if your particular set of requirements is in conflict with mine. I am really interested here in field-like events; if you’re implementing your own event accessors, then you know better than I do what you need.

The event pattern

For the following, suppose that you want a public event of type EventHandler. EventHandler is a delegate type that takes a “sender” object and some “args,” and it’ll serve as our example here, but it’s just a stand-in. Use any delegate you like. Anyway, the standard event pattern is the following:

public event EventHandler MyEvent;
protected void OnMyEvent(EventArgs e)
{
    EventHandler myEvent = MyEvent;
    if (myEvent != null)
    {
        myEvent(this, e);
    }
}

There are a few important details here:

1. This is exactly the same as the event pattern has always been. If you implemented C# 3 events this way, you’re golden.
2. It’s important that you copy the backing delegate field to a local in the “On...” method (see Synchronization below).
3. These members can have any accessibility you like, though a private event would be weird.

Synchronization

Never use “lock(this)” for any reason, especially not to synchronize any action you take on your events. You’ve probably heard enough of this by now, but in C# 3 this is unwise and in C# 4 it’s wrong. If you have an invocation of the delegate under a “lock(this)”, that’s especially awful, as it violates the idea that you should do as little as possible while holding a lock (you’re calling arbitrary event handlers!) and opens the door to deadlock. Instead...

Reads

If you want to read the value of your event delegate, it is safe to simply do so. If you test it and take further action on it, as in the “On...” method, then you should copy it to a local first. Otherwise there may be a mutation between the reads. Remember, delegates are immutable, and when the event delegate changes it’s just the reference that’s changing. Therefore all of your reads are effectively snapshots in time, and consecutive reads will represent intervening mutations. (Note: if it’s not clear, calling the delegate is a “read” operation because we’re talking about reading the reference).

Read-modify-writes

This is the purpose of event accessors, which += and -= allow access to. If you want to look at the event delegate, do something with it, and write the result back, you should use += and -=, which means you are limited to Combine and Remove. If these don’t suffice, you should probably consider implementing your own accessors and not using field-like events. Although it is possible to mimic the compare-and-swap that the C# 4 accessors provide, I don’t recommend it and I won’t put the code here; it’s very easy to get wrong.

Writes

If you want to write to the delegate without using any information about its current state, please do. The only reason I can imagine that one might do this is to say

myEvent = null;

in order to reset everything, but even in this case you need to be prepared that a client could call your add handler immediately following the reset.

Other

It’s kind of weird that this much attention has been paid to the safety of the event delegate via the accessors, given that your “On...” method is going to invoke the delegate on whatever thread it pleases. But precisely how the handlers are called (on what thread) is left as a matter of a contract between you and your clients. Be careful about that. Furthermore, that contract really ought to specify that the handlers should not throw—error recovery and multicast delegates don’t go together well. But again, this is a matter to settle between you and your clients.

Of course, if you have special knowledge that no one on any other thread can possibly call your accessors (e.g., you are in your constructor), then feel free to do whatever you want with your delegate field.

Single-threaded events

If you are operating in a single threaded environment, and are somehow encumbered by the synchronization that field-like events provide and which you determined that you do not want, write your own event as follows:

private EventHandler myEventField;
public event EventHandler MyEvent
{
    add { myEventField += value; }
    remove { myEventField -= value; }
}
protected void OnMyEvent(EventArgs e)
{
    if (myEventField != null)
    {
        myEventField(this, e);
    }
}

No-op Events

If you are required to implement an event that appears on an interface, but you never intend to call it, use this pattern for an empty event implementation.

interface I
{
    event EventHandler MyEvent;
}

class C
{
    event EventHandler I.MyEvent
    {
        add { }
        remove { }
    }
}

Virtual events

Never override a virtual event with a field-like event. The compiler does not handle this gracefully, and it never has. If you need to override virtual events, write your own handlers.

Events and co- and contravariance

Never expose an event of generic delegate type when that delegate type is covariant or contravariant in any of its type parameters. Examples of such delegates include all of the generic System.Actions and System.Funcs.

The problem is that in .NET 4, Delegate.Combine and Delegate.Remove will not work properly when two delegate instances have different actual types. This means that generally, multicast delegates of these “variant” types are dicey, and events in particular expose the Combine and Remove functionality pretty directly. When I say “will not work properly,” I mean they’ll throw.

By the way, the generic EventHandler, EventHandler<T>, is not contravariant in T precisely because of this limitation.

This may be remedied in future versions of the framework, but I am not on the team that owns delegates in the runtime and I don’t represent them, so I can’t make any promises.

And finally…

Sorry if this post is dry! I mostly want to make sure it’s up here for easy searchability. No more of this event stuff next time; I’m planning on writing a little more about dynamic.

And a note to those of you from the comments who want to hear about weakly referenced event handlers: perhaps later. There are some tricks to play, but also some fundamental incompatibilities with the way events and delegates are represented in .NET. But I hear you.

Now I’m here to tell you about some more in-your-face breaks that are a lot less subtle, and related to the binding change for += and -=. My hope is that anyone who actually sees these breaks will find this post and learn how to fix them. Let’s go.

Break #1: warning CS0067: The event 'MyClass.MyEvent' is never used

So imagine you have the following C# 3 code. It compiles just fine. No warnings, no errors. (Forget the about the actual utility of this piece of code for a moment).

using System;

class MyClass
{
    static void Main()
    {
        MyClass x = new MyClass();
        x.MyEvent += () => Console.WriteLine("Yay!");
    }
    public event Action MyEvent;
}

You upgrage to C# 4 and now you get a warning!

test.cs(10,25): warning CS0067: The event 'MyClass.MyEvent' is never used

What happened? Well, remember the subtle change in the way we interpreted += from the last post? It affects line 8 above. In C# 3, since this code is inside the class that defines the event, the += was a compound operator. Therefore it was a direct operation on the delegate field that backs MyEvent. In C# 4, however, we’ve changed the interpretation so that the += on line 8 is now calling the add accessor instead.

So why the warning? Because the warning is trying to tell you something about the private backing field, not the event accessors! In C# 4, this class has a delegate field that no one ever uses for anything. No one invokes it, no one passes it to Delegate.Combine, no one does anything with it. Of course the event accessors use it, but compiler generated code doesn’t count for this warning (and it never has).

The first possible fix here is: make use of the event! Perhaps you meant to raise the event, but you never got around to adding the code, and now this warning is actually telling you about a bug. If you were to add an “OnMyEvent” method that invoked MyEvent with “MyEvent()”, then you’ve made use of the field, the warning goes away, and you’ve fixed a bug.

The second fix is to get rid of the event, or at least the backing field. In this case, you don’t actually want to raise the event, and you might as well delete the thing. So you can safely remove the event and all the references to it and all’s well. It didn’t do anything anyway.

Of course, you might want to delete the event but be unable to. This can be the case if some base class or interface that you implement requires you to define the event. In that case, you probably have code like this:

interface IHasSomeEvent
{
    event Action SomeEvent;
}

class MyClass : IHasSomeEvent
{
    // there is a backing delegate here that goes unused!
    public event Action SomeEvent;
}

and my recommendation would be that you change your class to look like this:

class MyClass : IHasSomeEvent
{
    // this takes no storage and does nothing!
    event Action IHasSomeEvent.SomeEvent { add { } remove { } } 
}

This last case, where you are obligated to implement some event that you don’t care about, is the context in which I’ve seen these warning 67’s pop up most frequently. Notice that the fix I recommend actually does nothing more than fulfill the obligation of implementing the interface, and it doesn’t pollute the public surface area of your class with the event name. If you wanted to be especially hard-nosed, you could throw a NotImplementedException from those accessors, but that seems like a bit much to me.

Break #2: error CS0029: Cannot implicitly convert type 'void' to 'System.Action'

This break can also show up as “CS1503: Argument n: cannot convert from 'void' to 'System.Action'” or any of a few different errors where a conversion is required but does not exist. And it comes from code like this:

class MyClass
{
    event Action MyEvent;
    public void DoSomething()
    {
        Action a = MyEvent += () => Console.WriteLine("Yay!");
        a();
    }
}

Here, what we’re doing is adding the little Console.WriteLine delegate to my event, and then call the result. This works in C# 3, again, because += binds directly to the event. Therefore, the result of the compound assignment is the new delegate that is now referenced by MyEvent. However, in C# 4, since += is a call to an event add accessor, and the result of an event accessor call is void, you cannot directly look at the result like this. Event accessors are designed this way so that code outside your class can’t break encapsulation and get their hands on your delegates.

This is really weird code. I have never actually seen it in the wild. If you have such code, why not just call the accessor and then call the event?

class MyClass
{
    event Action MyEvent;
    public void DoSomething()
    {
        MyEvent += () => Console.WriteLine("Yay!");
        MyEvent();
    }
}

Other meaningless behavioral differences

There are a few other things that are different now that your +=’s are all calls to an accessor. But none that you should spend any time whatsoever worrying about; I list them here only to be thorough.

For instance, there’s another method call here. That could consume extra stack space. If you had just achieved the limit on your stack before, this one extra method call could push you over the edge and give you a StackOverflowException.

Also, there is a theoretical resource starvation problem with the compare and swap lock-free code when two threads sort of “line up” perfectly forever. This will affect you with probability zero.

And you could do silly things, such as: put a SecurityCriticalAttribute on your field-like event accessors (use the “method:” attribute target specifier), purely for the purpose of creating a situation wherein you can run in partial trust and a += in the event-defining class used to work in C# 3 but now it does not. Just... don’t do this.

Next time I’ll conclude this short series by going over the standard event pattern in C# 4, with recommendations about exactly how you should implement and use field-like events, and when you should not.

There are a few questions that came up in the comments, and two of them in particular are probably as straightforward as can be when you’re thinking about code that the compiler’s generating. First, is the code bigger? And second, is it slower? In this case, yes and no. Yes, the IL is 17 bytes bigger per accessor (not per instance), which will make your assembly that much bigger. Which is not fantastic news, but hey, 17 bytes. And no, the code is not slower. In fact, it’s faster! In tests that I’ve performed, when the delegate operations are as simple as possible the accessors appear to be about 20% to 25% faster. That’s because there’s no lock.

But neither of these issues are cause for concern or celebration. No, the big problem is that this change is an observable semantic difference between C# 3 and C# 4, and there is existing code that it could break. You see, you used to be able to protect against any change to your events over some block of code simply by putting the code in a “lock(this)”:

class OldClass
{
  public event EventHandler E;
  public void UseE()
  {
    lock (this)
    {
      // Safe in C# 3, unsafe in C# 4!
      E = (EventHandler)Delegate.Combine(E, new EventHandler(SecretHandler));
    }
  }
  private void SecretHandler(object sender, EventArgs e) { }
}

This code used to be effective, because inside the lock, we could be sure that no other thread would be changing the value of E between our read and our write. So this could not screw up E. Now, uh oh, it can! But just a minute, who writes code like this? Anyone who is going to call Delegate.Combine is probably going to do so with the + operator in C#:

class OldClass
{
  public event EventHandler E;
  public void UseE()
  {
    lock (this)
    {
      // Still safe in C# 3, unsafe in C# 4!
      E = E + SecretHandler;
    }
  } 
  private void SecretHandler(object sender, EventArgs e) { }
}

That calls Delegate.Combine in the same exact way. And actually, I suspect that anyone who writes that code is really going to write the following:

class OldClass
{
  public event EventHandler E;
  public void UseE()
  {
    lock (this)
    {
      E += SecretHandler;
    }
  } 
  private void SecretHandler(object sender, EventArgs e) { }
}

That code also calls Delegate.Combine, and we broke it too! This might be surprising to you. Look at it, the thing on the left of the += is an event, so surely this calls the event accessor, right? Nope! Let me take a quick detour here and explain to you how the binding of += works in C#. There are two possibilities: (1) either there is an actual + operator, such as with ints, and x += y binds to “x = x + y” except that x is only evaluated once. This is the compound assignment operator; or (2) the thing on the left hand side is an event, and x.E += y binds to “x.add_E(y)”. This is the event accessor operator, and in fact this is the only way to bind to an event accessor. So what do we have in the snippet above? Well, the extra bit of detail that you need to decide is the following rule about field-like events in C#: outside of the class or struct that defines a field-like event E, binding to the name E resolves to the event itself, on which the only legal operation is calling an accessor; inside the class or struct that defines a field-like event E, binding to the name E resolves to the private delegate field.

So in that last bit of code there, in “E += SecretHandler,” E is actually the delegate E, which has a +, not the event! So the binding you get is to Delegate.Combine (via +), not to the add accessor. And therefore, the explicit lock is the only thing that makes this safe in C# 3. Oh my! What have we done, and how can we fix it?

Well, it turns out that the binding in that last snippet of code is very surprising to most C# developers who have encountered it. It’s so surprising that I would say that in 99% of the cases, the developer thinks they are calling the accessor and so they don’t even put the lock in:

class OldClass
{
  public event EventHandler E;
  public void UseE()
  {
    // Unsafe in C# 3!
    E += SecretHandler;
  }
  private void SecretHandler(object sender, EventArgs e) { }
}

But you cannot call the event accessor from inside the class that defines it. There’s a simple fix, though. Now we let you call the add accessor this way!

I hope I haven’t lost you, since this is actually quite subtle and you probably were unaware of the binding rule I outlined above. But that’s the rule that we had in C# 3. In C# 4, however, the new rule is that inside your class with field-like event E, the name E binds to the backing delegate field (so you can call it, for instance), except when it’s the left hand side of a += or –=, in which case it becomes the event.

This change fixes the code in C# 3, which you might not have even known was broken. Heck, even if you were among the small fraction of people who knew that events took care of some synchronization for you, you still probably didn’t know this was broken. I know this because there is a constant slow trickle of people who email us having discovered this the hard way. And we now we fixed them.

But we also fixed, to some degree, the problem with the new C# 4. If you wrote “E += Handler” in your class, now you get the benefit of our new synchronization whether or not you put the “lock(this)” there. Which is great, because you don’t want to write that synchronization yourself.

Ok, ok, there’s more. But I’ll leave it at that until Part III.

Read this old post to refresh yourself, if you care. The cause for alarm, through C# 3, was that when you declared events, the compiler made event accessors that took a lock on the “this” sync block, or worse. This meant that calls to the accessors were safe to make on multiple threads, but it is bad design that could cause deadlocks, and made it hard to program lock-free using events.

Let’s have a look at what changed. Suppose we have the following simple event declaration:

class Control
{
    public event EventHandler OnClick;
}

In C# 3, we generated event handlers that looked something like this

class Control
{
    private EventHandler __OnClick; // This is the backing field
    public event EventHandler OnClick
    {
        add { lock (this) { __OnClick = __OnClick + value; } }
        remove { lock (this) { __OnClick = __OnClick - value; } }
    }
}

That old post explains it in some detail, but the overall badness comes from the lock. You should never lock “this.” So, the question becomes, what can we do to improve the codegen here?

Well, we really have to get rid of that lock. There are a variety of options available to us. We can just delete the lock entirely and leave the delegate operations naked. Or we can replace it with a lock on something safe (say, a field we’d create just for this purpose in your class). Or we can introduce some other synchronization mechanism.

If we got rid of the lock, though, that would really be a problem for people who need this synchronization. After all, it was added for a reason, and surely people are relying on it. As for the second option, well, that would bloat your instances all by a reference, which you might or might not care about, but someone does. After all, the compiler is going to be doing this for everyone who uses field-like events.

So, we went with option three. Now, the compiler generates something like this:

class Control
{
    private EventHandler __OnClick; // This is the backing field
    public event EventHandler OnClick
    {
        add { /* lock-free synchronization code that updates __OnClick */ }
        remove { /* lock-free synchronization code that updates __OnClick */ }
    }
}

Well, that’s not so instructive, but I don’t want to sidetrack you with the details of exactly what the code looks like (it’s a compare-and-swap). It’s interesting, but it’s not the point (go look at your classes with ildasm and you can see it; we’ll talk later). With this new code, in C# 4, your event accessors will have the following characteristics:

1. The accessors do not use the Monitor class at all, and can therefore be used in an environment that is hostile to locks, such as SQLCLR.
2. For each field-like event, all add and remove calls will be effectively serial, regardless of the threads the calls take place on. Adds and removes on separate events can happen simultaneously, but that’s no problem.
3. This synchronization works for instance events and static events, and it works in reference types (classes) as well as value types (structs). This is an improvement over the previous model that did not support value types.

These are really good things. But there is some cost; unfortunately it’s not all Tootsie Rolls and unicorns. I’ll follow up with more about the downsides in the next few posts, as well as other compiler changes that mitigate them.