A Simple Explanation of C# Closures

what an interesting concept! actually makes me miss college and all this crazy computer sciencey stuff was still new. thanks for the insight!

Excellent! That’s one less thing off of my "things to learn when I have the time" list!

@Andy H: A "lexical environment" means "scope".

As for where it would make sense, that depends on what you’re doing. 🙂

A cursory grep of some sources I have shows this use of closures:

var data = new int [7];
var result = new int [] { 6, 7, 8, 9, 10, 11, 12 };

int j = 0;
6.UpTo (12).ForEach (i => { data [j++] = i; });

AssertAreSame (result, data);

This is to test an Int32.UpTo(int, int) extension method, and uses an IEnumerable<T>.ForEach(Action<T>) extension method for the testing. Since we can’t provide additional parameters to .ForEach(), we rely on a closure over the ‘data’ and ‘j’ variables, allowing for `data[j++]=i`, where `i` is a parameter to the lambda.

A simpler (but likely sillier) example would be this:

Func<int, int> IncrementBy (int by)
{
return value => value + by;
}

In the above, `by` is captured in a closure, allowing:

Func<int, int> inc1 = IncrementBy (1);
Console.WriteLine (inc1 (2)); // == 3
Func<int, int> inc9 = IncrementBy (9);
Console.WriteLine (inc9 (2)); // == 11

The primary motivation for closures is that it allows for more succinct code, as you need to modify fewer "intermediate" layers to provide additional "contextual" data; consider a Linq-to-SQL query that does name matching:

IQueryable<Person> GetManagersWithName (IQueryable<Person> people, string name)
{
return from p in people
where p.Name == name && // implicit closure over ‘name’
p.PersonType == PersonType.Manager
select p;
}

Without closures, we’d either need to copy&paste the entire body into each code site (yay maintenance! so much for DRY!) or complicate the calling code. (There are times in C++ where, since I couldn’t use a closure, I had to add additional member variables to a class and change the argument lists of multiple methods so that the contextual data I needed was "passed down" through all the intermediate methods. It’s NOT FUN.)

Excellent. Couldn’t have said it myself better 🙂

Thank you both Justin and Jonathan for the wonderful tips.

I read a lot of programming blogs/websites. This is one of the best posts on anything I’ve ever read. Heading to the other parts of the site now…

Closures were added in version C# 2. It was VB that didn’t get them until .NET 3.

http://joe.truemesh.com/blog/000390.html

@Jonathan Thanks, I’m aware, when I said function programming goodness I was referring to all of the additional functionality we got with C# 3.0 which makes it more often used. I don’t know about you, but I never really saw people using anonymous methods very often. 🙂

But anyways, you are correct, anonymous methods were added in C# 2.0 and you can create closures with them.

please try following to examples, the behavior of "close over" the free variable is inconsistent:

============================================

class Program
{
static void Main(string[] args)
{
var multiple = 2;

Func<int, int> fun_double = GetAFunc(multiple);

multiple = 3;

Func<int, int> fun_triple = GetAFunc(multiple);

Console.WriteLine(fun_double(5));
Console.WriteLine(fun_triple(5));
return;
}

public static Func<int,int> GetAFunc(int multiple)
{
Func<int, int> functor = delegate(int var1)
{
return var1 * multiple;
};
return functor;
}

}

===============================================

class Program
{
static void Main(string[] args)
{
var multiple = 2;

Func<int, int> fun_double = delegate(int var1)
{
return var1 * multiple;
};

multiple = 3;

Func<int, int> fun_triple = delegate(int var1)
{
return var1 * multiple;
};

Console.WriteLine(fun_double(5));
Console.WriteLine(fun_triple(5));
return;
}

This is the first explanation of closures I’ve read that actually make sense 🙂
Thank you so much, I am, for the first time, confident that I get the concept (bow)

Short version:

int n = 1;
var f = new Func<int, int>(a => a += (n += 1));
Console.WriteLine(f(5));
Console.WriteLine(f(6));

@Justin, @abc is *correct*. From a functional programmer’s point of view C# has actually done closures *wrong*. A closure is properly created using the value bound in the lexical environment – yet the value that C# binds in the lambda’s scope is in fact a reference to the value.

In fairness, doing such a thing is not strictly *incorrect*, but it has been tried in various contexts and found wanting. The most obvious one being the original semantics for a Smalltalk block expression. What C# has created is a language that is lexically scoped, *except* for lambdas which are dynamically scoped. Consistent lexical scoping is actually preferable, as you can always arrange some way to communicate changes, whereas freezing the data in time turns out to be what is wanted about 85% of the time.

just wanted so say: WOW, beautifully explained 🙂

Thanks man! keep it up! 🙂

I have to thank you from keeping me from reading through thousands of confusing explanations of something so simple. I usually like to remember my explanations in a simple way like this, it’s just getting there that is the problem. You deserve a freaking medal!

Thanks, great explanation!

Great, easy to understand. Thank you.

btw, you’re the first thing that google returns from “C# Closure”.

I saw a question on StackOverflow about closures and had no idea what they were. I googled it and found this beautiful and simple explanation. Thank you!

In Visual Studio 2012, the output of your program is 7 and 8. Looks like they have changed something with the closures in .NET 4.5